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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by IMS Network Testing (INT). 

The present document is part 2 of a multi-part deliverable covering the IMS NNI Interworking Test Specifications, as 
identified below: 

Part 1 : "Test Purposes for IMS NNI Interworking"; 

Part 2: "Test Descriptions for IMS NNI Interworking"; 

Part 3: "ATS&PIXIT". 
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1 Scope 

The present document specifies interoperability Test Descriptions (TDs) for IMS NNI interoperability testing for the IP 
Multimedia Call Control Protocol based on Stage 3 Session Initiation Protocol (SIP) and Session Description Protocol 
(SDP) standard, ES 283 003 [1]. TDs have been specified on the basis of the Test Purposes (TPs) and Test Suite 
Structure (TSS) presented in TS 186 01 1-1 [2]. TP fragments presented in the present document as part of TDs are 
defined using the TPLan notation of ES 202 553 [5]. TDs have been written based on the test specification framework 
described in TS 102 351 [3] and the interoperability testing methodology defined in TS 102 237-1 [4], 
i.e. interoperability testing with a conformance relation. 

For the assessment of IMS core network requirements related to the ISC interface parts of the supplementary services 
HOLD (see TS 124 410 [10]), CDIV (see TS 124 404 [11]), ACR-CB (see TS 124 41 1 [12]), and OIP/OIR 
(see TS 124 407 [13]) have been used. 

The scope of these test descriptions is not to cover all requirements specified in ES 283 003 [1]. TDs have been only 
specified for requirements that are observable at the interface between two IMS core network implementations, i.e. IMS 
NNI. 

NOTE: Requirements pertaining to a UE or an AS implementation or IMS core network requirements that can 
only be observed at the interface between UE and IMS CN are explicitly not within the scope of the 
present document. The latter requirements have been dealt with from a UE and conformance perspective 
in TS 134 229 [6]. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox. etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 283 003 (VI. 8.0): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
(Release 7), modified]". 

[2] ETSI TS 186 011-1 (V2.0.0): "Technical Committee for IMS Network Testing (INT); IMS NNI 

Interworking Test Specifications; Part 1: Test Purposes for IMS NNI Interworking". 
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[3] ETSI TS 102 35 1 : "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT); 

IPv6 Testing: Methodology and Framework". 

[4] ETSI TS 102 237-1: "Telecommunications and Internet Protocol Harmonization Over Networks 

(TIPHON) Release 4; Interoperability test methods and approaches; Part 1: Generic approach to 
interoperability testing". 

[5] ETSI ES 202 553: "Methods for Testing and Specification (MTS); TPLan: A notation for 

expressing Test Purposes". 

[6] ETSI TS 134 229: "Universal Mobile Telecommunications System (UMTS); Internet Protocol (IP) 

multimedia call control protocol based on Session Initiation Protocol (SIP) and Session 
Description Protocol (SDP); Part 1: Protocol conformance specification (3GPP TS 34.229-1 
Release 7)". 

[7] ETSI TS 133 203: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); 3G security; Access security for IP-based services 
(3 GPP TS 33.203 Release 7)". 

[8] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication". 

[9] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[10] ETSI TS 124 410: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; NGN Signalling Control Protocol; 
Communication HOLD (HOLD) PSTN/ISDN simulation services; Protocol specification 
(3GPP TS 24.410 Release 7)". 

[11] ETSI TS 124 404: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services: 
Communication Diversion (CDIV); Protocol specification (3GPP TS 24.404 Release 7)". 

[12] ETSI TS 124 411: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services: Anonymous 
Communication Rejection (ACR) and Communication Barring (CB); Protocol specification 
(3GPP TS 24.411 Release 7)". 

[13] ETSI TS 124 407: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); TISPAN; PSTN/ISDN simulation services; Originating 
Identification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol 
specification (3GPP TS 24.407 Release 7)". 



2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 133 978: "Universal Mobile Telecommunications System (UMTS); Security aspects of 

early IP Multimedia Subsystem (IMS) (3GPP TR 33.978 version 7.0.0 Release 7)". 

[i.2] ETSI TR 123 981: "Universal Mobile Telecommunications System (UMTS); Interworking aspects 

and migration scenarios for IPv4-based IP Multimedia Subsystem (IMS) implementations 
(3GPP TR 23.981 Release 7)". 
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3 Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



3GPP 


3 rd Generation Partnership Project 


ACR 


Anonymous Communication Rejection 


AKA 


Authentication and Key Agreement 


AS 


(IMS) Application Server 


CB 


Call Barring 


CDIV 


Call Diversion 


CF 


(Test) ConFiguration 


CFU 


Call Forward Unconditional 


CFW 


Call FloW 


CN 


Core Network 


CSCF 


Call Session Control Function 


DHCP 


Dynamic Host Configuration Protocol 


DNS 


Domain Name System 


ENUM 


E. 164 Number Mapping 


HOLD 


Communication HOLD 


HSS 


Home Subscriber Server 


IBCF 


Interconnection Border Control Gateway 


I-CSCF 


Interrogating CSCF 


IMS 


IP Multimedia Subsystem 


IOI 


Inter Operator Identifier 


IP 


Internet Protocol 


IPsec 


Internet Protocol security 


ISC 


IMS Service Control 


NNI 


Network-to-Network Interface 


OCB 


Outgoing Communication Barring 


OIP 


Originating Identification Presentation 


OIR 


Originating Identification Restriction 


PCO 


Point of Control and Observation 


P-CSCF 


Proxy CSCF 


PO 


Point of Observation 


PSTN 


Public Switched Telephone Network 


SA 


Security Association 


S-CSCF 


Serving CSCF 


SDP 


Session Description Protocol 


SIP 


Session Initiation Protocol 


SUT 


System Under Test 


TCP 


Transmission Control Protocol 


TD 


Test Description 


TISPAN 


Telecommunications and Internet converged Services and Protocols for Advanced Networking 


TP 


Test Purpose 


TPLan 


Test Purpose Notation 


TSS 


Test Suite Structure 


UC 


Use Case 


UE 


User Equipment 


URI 


Uniform Record Identifier 


VoIP 


Voice over Internet Protocol 


XML 


Extensible Markup Language 
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4 IMS NNI Interoperability Test Specification 

4.1 Introduction 

The IMS NNI Interoperability Test Descriptions (TDs) defined in the following clauses are derived from the Test 
Purposes (TPs) specified in TS 186 01 1-1 [2]. The TDs cover both basic call procedures such as call establishment and 
call release and a selection of the most common supplementary services. 

4.2 Test Prerequisites 

4.2.1 IP Version 

These test specifications are based on the use of IPv4 for SIP message transport throughout all IMS nodes as specified 
in TR 123 981 [i.2]. 

4.2.2 Authentication and Security 

The current test specification supports as default full IMS TS 133 203 [7] 3GPP security. Non-compliance with full 
IMS security features defined in TS 133 203 [7] is expected to be a problem mainly at the UE side, because of the 
potential lack of support of the USIM/ISIM interface (especially in 2G-only devices) and of the potential inability to 
support IPsec on some UE platforms. For those reasons, fallback to early IMS TR 133 978 [i.l] and SIP Digest 
authentication without key agreement and null authentication may be used to achieve satisfactory test results. Tests 
should however be executed with full IMS security if all required IMS nodes support it. 

4.2.3 Registration and Subscription 
4.2.3.1 SIP Call Flow 

This clause describes the registration call flow under the authentication and security scope described in clause 4.2.2. 

4.2.3.1 .1 Early IMS Registration and Subscription Call Flow 



Early IMS security does not allow SIP requests to be protected using an IPsec Security Association (SA) because it does 
not perform a key agreement procedure. IPsec security associations are not set up between UE and P-CSCF, as they are 
in the full IMS security solution. For early IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


Message 


Comment 




UE | IMS 




1 








The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 






P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 




REGISTER 


The UE sends initial registration for IMS services. 




4 




200 OK 


The IMS responds with 200 OK. 




5 




SUBSCRIBE 


The UE subscribes to its registration event 
package. 


-o 

w 


6 


<- 


200 OK or 202 Accepted 


The IMS responds with 200 OK or 202 Accepted. 


o 
w 


7 




NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 


Unpro 


8 




200 OK 


The UE responds with 200 OK. 
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4.2.3.1 .2 Full IMS Registration and Subscription Call Flow 



For full IMS security, the expected registration and subscription sequence is: 



Step 


Direction 


Message 


Comment 




IIP I IMQ 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 






P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 




REGISTER 


The UE sends initial registration for IMS services. 




4 




401 Unauthorized 


The IMS responds with a valid Digest AKA 
authentication challenge and a list of integrity and 
encryption algorithms supported by the network as 
defined in the IMS AKA procedure of 
TS 133 203 [7]. 


Unprotectec 


5 






Upon receipt of 401 Unauthorized, the UE selects 
the first integrity and encryption algorithm 
combination on the list received from the P-CSCF in 
401 Unauthorized which is also supported by the 
UE. If the P-CSCF did not include any 
confidentiality algorithm in 401 Unauthorized then 
the UE shall select the NULL encryption algorithm. 
The UE then proceeds to establish two new pairs of 
IPSEC Security Associations (SA1 and SA2). 




6 




REGISTER 


The UE sends another REGISTER with 
authentication credentials over IPSEC security 
association SA1 . 


i by SA1 


7 




200 OK 


The IMS responds with 200 OK over the same 
IPSEC security association SA1 . 


Protectee 


8 


-r 


SUBSCRIBE 


The UE subscribes to its registration event package 
over the IPSEC security association SA2. 




9 




200 OK or 202 Accepted 


The IMS responds with 200 OK or 202 Accepted 
over the IPSEC security association SA2. 


CM 
< 


10 


<- 


NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body, over the IPSEC security association 
SA2. 


Protected by 


11 




200 OK 


The UE responds with 200 OK over the IPSEC 
security association SA2. 
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4.2.3.1 .3 SIP Digest Registration and Subscription Call Flow 



For SIP Digest authentication without key agreement and null authentication, the expected registration and subscription 
sequence is: 



Step 


Direction 


Message 


Comment 




UE IMS 




1 






The UE establishes an IP bearer as required by its 
specific access network (optional). 




2 






P-CSCF address discovery using DHCP 
procedures for IPv4 (optional). 




3 




REGISTER 


The UE sends initial registration for IMS services. 




4 




401 Unauthorized 


The IMS responds with a valid HTTP Digest 
authentication challenge as defined in RFC 2617 

roi 

[8]. 




5 




REGISTER 


The UE sends another REGISTER with 
authentication credentials. 


T3 

m 


6 




200 OK 


The IMS responds with 200 OK. 


iprotecti 


7 




SUBSCRIBE 


The UE subscribes to its registration event 
package. 


8 




200 OK or 202 Accepted 


The IMS responds with 200 OK or 202 Accepted. 




9 




NOTIFY 


The IMS sends initial NOTIFY for registration event 
package, containing full registration state 
information for the registered public user identity in 
the XML body. 




10 




200 OK 


The UE responds with 200 OK. 





4.2.4 Supported Options 

4.2.4.1 Security 

Support for security agreement is optional in case of Full IMS Reg. It shall only be used in case all IMS nodes support 
it. 

4.2.4.2 Signalling Compression 

"No SigComp" is the default signalling configuration in all test descriptions. Tests may be executed with signalling 
compression if the required nodes support it. 

4.3 Test Infrastructure 

In these clauses we define the involvement of the various IMS nodes specifically as they pertain to NNI testing. The 
configuration of the nodes is described. Points of control and observation are identified and static test configurations are 
described. The Mw interface or the Ic interface if topology hiding is required is the interface under observation for NNI 
interoperability testing. 

4.3.1 Core IMS Nodes 

Because the current testing scope excludes IMS roaming and border control functionality, P-CSCF, S-CSCF, I-CSCF, 
IBCF, and HSS are considered to be within a "black box" for testing purposes, i.e. the System Under Test (SUT). 
Interfaces within the IMS are considered internal and not observable for testing purposes. 
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4.3.1.1 P-CSCF 

4.3.1.1.1 Relevant Interfaces 

The P-CSCF constitutes the point of entry for UE signalling into the IMS core. The Gm interface between the P-CSCF 
and the UE is used as a point of control and observation (PCO) for NNI interoperability testing purposes. In the case of 
IMS roaming configurations where no topology hiding is applied the Mw interface of the P-CSCF is exposed at the NNI 
and used there as a point of observation (PO). 

4.3.1.1.2 Node Configuration 

The P-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.2 S-CSCF 

4.3.1.2.1 Relevant Interfaces 

The S-CSCF is the core IMS node delivering IMS services to subscribers. When no topology hiding is applied, the Mw 
interface between the S-CSCF and either I- or S-CSCF in another network domain is used as a PO against which NNI 
interoperability tests are validated. The Mw interfaces between I- and S-CSCFs within the same network are considered 
to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test configurations, 
it is recommended that these interface are exposed for troubleshooting purposes. 

4.3.1 .2.2 Node Configuration 

The S-CSCF should be configured to support the pre-requisites outlined in clause 4.2. When applicable based on the 
specific configuration, the S-CSCF must be provisioned to support required Application Servers (AS) as trusted nodes. 

4.3.1.3 l-CSCF 

4.3.1.3.1 Relevant Interfaces 

The I-CSCF is the contact point within an operator's network for all connections destined to a user of that network 
operator, or a roaming user currently located within that network operator's service area. When no topology hiding is 
applied, the Mw interface between the I-CSCF and an S-CSCF in another network domain is used as a PO against 
which NNI interoperability tests are validated. The Mw interfaces between I- and S-CSCFs within the same network are 
considered to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test 
configurations, it is recommended that these interface are exposed for troubleshooting purposes. 

4.3.1 .3.2 Node Configuration 

The I-CSCF should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1.4 IBCF 

4.3.1.4.1 Relevant Interfaces 

The IBCF is the core IMS node providing functionalities such as topology hiding, transport plane control or screening 
of SIP signalling. However, the IBCF can act also as a pass-through entity between adjacent IMS networks. The Ic 
interface between the IBCF and either IBCF or I- or S-CSCF in another network domain is used as a PO against which 
NNI interoperability tests are validated. The Mw interfaces between IBCF and I- or S-CSCFs within the same network 
are considered to be internal IMS interfaces. Although considered as internal and not explicitly involved in all NNI test 
configurations, it is recommended that these interfaces are exposed for troubleshooting purposes. 
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4.3.1.4.2 Node Configuration 

The IBCF should be configured to support the pre-requisites outlined in clause 4.2. The need to activate the IBCF as 
part of an IMS core network depends highly on the test description to be executed. In case the requirement to support 
topology hiding is not explicitly stated in the pre-conditions of a test description it shall be assumed that the IBCF is not 
activated and acts merely as a pass-through entity. 

4.3.1.5 HSS 

4.3.1.5.1 Relevant Interfaces 

The HSS constitutes the repository for IMS subscriber information. The Cx interface between the HSS and the S-CSCF 
and/or I-CSCF is considered an internal IMS interface. 

4.3.1.5.2 Node Configuration 

The HSS should be configured within each IMS participating in an interoperability test, i.e. IMS_A as well as IMS_B, 
to interact with CSCFs as required using DIAMETER Cx interfaces. Users should be provisioned to match the sample 
profiles listed in table 1 . In addition, each IMS shall have its own unique domain. Also the phone numbers configured in 
the two IMSes participating in an interoperability test shall be unique, i.e. IMS_A and IMS_B shall have no phone 
numbers in common. All public identities belong to the same implicitly registered set. 



Table 1 : HSS sample user profiles 



Private Identity 


Public Identity 1 
(SIP URI) 


Public Identity 2 
(Tel URI) 


Default 
Public 
Identity 


Filter criteria 


userGEN_priv 


userGEN 


na 


1 


na 


userSIP_priv 


userSIP 


e.g. tel:+3301 23402 


1 


na 


userTEL_priv 


userTEL 


e.g. tel:+3301 23403 


2 


na 


userNOAS_priv 


userNOAS 


na 


1 


contact AS on terminating INVITE 
SESSION TERMINATED 


userHOLD_priv 


userHOLD 


na 


1 


contact HOLD AS 


userOIP_priv 


userOIP 


na 


1 


contact OIP AS 


userOIR_priv 


userOIR 


na 


1 


contact OIR AS 


userACR_priv 


userACR 


na 


1 


contact ACR AS 


userCFU_priv 


userCFU 


na 


1 


contact CFU AS 



Public user identity may take the form of SIP or TEL URIs (RFC 3966 [9]). 

EXAMPLE 1: sip: userGEN@ims_a.net. 

EXAMPLE 2: tel: +330123402. 
A private user identity may also take the form of- <imsi>@ims.<xxx>mnc.<yyy>. mcc.3gppnetwork.org. 

EXAMPLE 3: 293410100367663@ims.041mnc.293.mcc.3gppnetwork.org. 

4.3.2 External IMS Nodes 
4.3.2.1 UE 

4.3.2.1.1 Relevant Interfaces 

The UE is considered to act as a stimulus node in this test specification. The Gm interface between the P-CSCF and the 
UE is used as a Point of Control and Observation (PCO) for NNI interoperability tests. 
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4.3.2.1 .2 Node Configuration 

The UE should be configured to support the pre-requisites outlined in clause 4.2. The test descriptions in the present 
document assume that a UE supports basic call and messaging functionality, target refresh based on UPDATE and on 
re-INVITE method, message transport via UDP and TCP, and the use of at least one of the supplementary services 
HOLD (see TS 124 410 [10]), CDIV (see TS 124 404 [11]), ACR-CB (see TS 124 41 1 [12]) or OIP/OIR 
(see TS 124 407 [13]). In the case that a UE does not meet one or more of these features, only a selected subset of the 
test descriptions in this document should be used for IMS core network interoperability testing, i.e. test descriptions 
which do not contain any pass criteria related to these features. 

4.3.2.2 AS 

4.3.2.2.1 Relevant Interfaces 

The Application Server (AS) is considered to act as a stimulus node in this test specification. The ISC interface between 
the S-CSCF and the AS is used as a Point of Control and Observation (PCO) for NNI interoperability tests. 

4.3.2.2.2 Node Configuration 

The AS should be configured to support the pre-requisites outlined in clause 4.2. The test descriptions in the present 
document assume that an AS supports the use of the supplementary services HOLD (see TS 124 410 [10]), CDIV 
(seeTS 124 404 [11]), ACR-CB (see TS 124 411 [12]), and OIP/OIR (see TS 124 407 [13]). In the case that an AS does 
not support one or more of these supplementary services, only a selected subset of the test descriptions in the present 
document should be used for IMS core network interoperability testing, i.e. test descriptions which do not contain any 
pass criteria related to these supplementary services. 

4.3.3 Supporting IMS Nodes 
4.3.3.1 DNS 

4.3.3.1.1 Relevant Interfaces 

The Domain Name Service (DNS) is considered as a supporting entity in this test specification. It is assumed that each 
IMS has its own local DNS which is connected to the common interconnect DNS. 

4.3.3.1 .2 Node Configuration 

The common DNS should be configured for appropriate resource record handling as required to support proper 
resolution of all SIP URIs in Request URIs and Route headers. In addition, either the local or common DNS must 
support ENUM functionality in order to resolve Tel URIs into SIP URIs. As an example, a DNS should have an entry to 
map E.164 number 0633348273 to the SIP URI of userSIP. 

4.3.4 Test Configurations 

The following architectural test configurations are referenced in the IMS NNI interoperability TDs in the present 
document. They are intended to give a general rather than a specific view of the required IMS core network SUT(s) 
connectivity and associated UE(s), AS(s), and DNS(s). 

NOTE: Note that in the following figures observable interfaces are indicated as a solid line, non-observable 

interfaces indicated as dashed lines, and IBCFs are assumed to act in a "pass-through" mode if topology 
hiding is not required by a test description. In addition, local DNS servers are not shown. 
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Roaming Registration 
CF ROAM REG 



UE 



Gm 







PCO 



IMS A 



P-CSCF 



l-CSCF 



HSS 



S-CSCF 



IBCF 



Mw 



HSS 



IBCF 



IMS B 



S-CSCF 




P-CSCF 


v / 




\ ) 









l-CSCF 



PO 

Precondition: 

Different network operators performing origination and termination, UE_B roaming in Home network A 
(ROAM), UE_B not yet registered (REG), neither UE_A nor AS involved, IBCF may be involved 

Test configuration for: 

Registration requests and responses from UE_B 

Example: 

REGISTER prior to IMS VoIP voice call from UE_B 



Figure 1 : CF ROAM REG 



Interworking Call 



CF_INT_CALL 




PO 



Precondition: 

Different network operators performing origination and termination, both UEs or only UE A in home 
networks (INT), both UE's registered, no AS, a common interconnect DNS and local DNSs for each 
IMS may be involved, IBCF may be involved 
Test configuration for: 

Requests and responses between UE_A and UE_B in call (CALL) and messaging scenarios 
Unsuccessful initial requests and responses from UE_A (when UE_B is not registered) 
Example: 

Initial INVITE in IMS VoIP voice call from UE AtoUE B 



Figure 2: CF INT CALL 
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Roaming Call 
CF_ROAM_CALL 




Precondition: 

Different network operators performing origination and termination, UE_B roaming (ROAM) via 
IMS_A, UE_A in home network, both UEs are registered, no AS, IBCF may be involved 
Test configuration for: 

Requests and responses between UEB and UE_A in call (CALL) and messaging scenarios 
Example: 

Initial INVITE in IMS VoIP voice call from UE B to UE A 



Figure 3: CF ROAM CALL 



Interworking Application Server 
CF INT AS 



Gm 



PCO 
ISC 



AS 
A 



PCO 



IMS A 



l-CSCF 



HSS 



'LIE' 


-0- 




' P-CSCF ^ 




' S-CSCF S 


A 























[ IBCF 



i 
i 

\. 



Mw 







PO 



HSS 



IMS I 



' S-CSCF ^ 




' P-CSCF 














\ IBCF X | 


r l-CSCF 


i 


L 




i 
i 


J 





Gm 







PCO 



UE 
B 



Precondition: 

Different network operators performing origination and termination, UE_A and UE_Bin home networks 

(INT), both UEs registered, only AS for UE_A (AS), IBCF may be involved 
Test configuration for: 

Requests and responses between AS_A and UEs 
Example: 

Initial INVITE in IMS VoIP voice call unconditionally forwarded to UE_B by AS_A (CFU). AS_A acts 
as routing AS 



Figure 4: CF_INT_AS 
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Roaming Application Server 
CF ROAM AS 




Precondition: 

Different network operators performing origination and termination, UE_B roaming (ROAM) via 
IMS_A, UE_A in home network, both UEs or registered, AS for UE_A and LIE B may be involved 
(AS), IBCF may be involved 
Test configuration for: 

Requests and responses between AS_B and UEs 

Unsuccessful initial requests and responses from UE_A (when UE_B and AS_B are not available) 
Example: 

Initial INVITE IMS VoIP voice call unconditionally forwarded to UE_B by AS_B (CFU). AS_B acts 
as routing AS 

Figures: CF_ROAM_AS 



4.4 Use Cases 

Use cases are the basis for interoperability test descriptions. Each use case defines both a generic test sequence, i.e. a set 
of user stimuli and observations for any number of involved IMS external entities (IMS UE, DNS Server, and AS), and 
a monitor view of all the resulting messages exchanged at the outer IMS core network interfaces, i.e. a call flow for 
user, Gm, Mw, Ic, DNS, and ISC interfaces. The test sequence and call flow are correlated using grey shading. 

For call and messaging related use cases presented in this clause that involve UE interaction it is assumed to follow the 
registration and subscription procedure described in clause 4.2.4 for each UE involved in the test. These procedures are 
not shown here to reduce the size of the call flows. 

Test descriptions defined in clause 4.5 then reference and specialize one of the use cases presented in this clause, 
i.e. generic test sequence and call flow, according to the needs of the one or more test puiposes which are associated 
with a test description. 

4.4.1 IMS Registration in a Visited Network 
4.4.1.1 Description 

UE_B registers in a visiting network. The call flow path and node configuration for this use case corresponds to 
CF_ROAM_REG. 
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The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering). 



Step 


Action 


CF_ROAM_REG 


1 


User B triggers registration to IMS B 


Step 1 


2 


User B is informed about successful registration 


Step 22 



4.4.1 .2 UC_01_R: SIP message flow for IMS registration with CF ROAM 

The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


s 


E 


M 


M 


e 


B 


s 


s 


r 




A 


B 


B 









10 



11 



12 



13 



14 



15 



16 



17 



18 



19 



20 



21 



22 



User B triggers registration to IMS B 



REGISTER 



UE B sends a REGISTER to IMS A 



REGISTER 



IMS A forwards the REGISTER to IMS B 



401 Unauthorized 



IMS_B responds with 401 Unauthorized to 
IMS A 



401 Unauthorized 



IMS A forwards the 401 Unauthorized to UE B 



REGISTER 



UE_B sends the same REGISTER containing 
authentication challenge response to IMS_A 



REGISTER 



IMS A forwards the REGISTER to IMS B 



200 OK 



IMS_B responds with 200 OK 



200 OK 



IMS_A forwards the 200 OK response to UE B 



SUBSCRIBE 



IMS A sends a SUBSCRIBE to IMS B 



200 OK or 
202 Accepted 



IMS_B responds with a 200 OK or 202 
Accepted 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



200 OK 



IMS_A responds to the NOTIFY with a 200 OK 



SUBSCRIBE 



SUBSCRIBE 



UE_B sends a SUBSCRIBE (reg event 
package) to IMS_ A 



IMS_A forwards the SUBSCRIBE request to 
IMS B 



200 OK or 
202 Accepted 



IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 



200 OK or 
202 Accepted 



NOTIFY 



IMS_A forwards the 200 OK or 202 Accepted 
response to UE_B 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



NOTIFY 



IMS A forwards the NOTIFY to UE B 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 



User B is informed about successful registration 



4.4.2 User-initiated VoIP call setup and release 
4.4.2.1 Normal Call 
4.4.2.1.1 Description 

UE_A places an IMS VoIP call to UE_B. Once the media path is established, the originating user releases the call. The 
call flow path and node configuration for this use case corresponds to CF_INT_CALL in case of interworking and 
CF_ROAM_CALL in case of roaming. 
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The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering). 



4.4.2.1 .2 UC_02_I: SIP Call Flow "Normal Call" with CF INT CALL 

The test sequence and expected call flow sequence when user A calls user B in an interworking scenario is: 



Step 


Action 


CF INTCALL 


1 


User A calls User B 


Step 1 


2 


User B is informed of incoming call of User A 


Step 8 


3 


User A is informed that UE B is ringing 


Step 12 


4 


User B answers call 


Step 13 


5 


User A is informed that call has been answered 


Step 17 


6 


User B is informed that the call is established 


Step 21 


7A 


User A ends call 


Step 22A j 


7B 


User B ends call 


Step 22B 


8A 


User B is informed that call has ended 


Step 26A j 


8B 


User A is informed that call has ended 


Step 26B 


9A 


User A is informed that call has ended 


Step 30A 


9B 


User B is informed that call has ended 


Step 30B 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



10 



11 



12 



13 



14 



15 



16 



17 



19 



20 



21 



22A 



23A 



24A 



25A 



User A calls User B 



INVITE 



100 Trying 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of I 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



200 OK 



UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 


ACK 


IMS_A forwards ACK to IMS_B 


ACK 


IMS_B forwards ACK to UE_B 




User B is informed that the call is established 



BYE 



BYE 



BYE 



UE_A releases the call with BYE 



IMS A forwards BYE to IMS B 



IMS B forwards BYE to UE B 
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Step 


Direction 


Message 


Comment 




U 

s 
e 
r 
A 


U 
E 
A 


I 

M 

S 
A 


I 

M 

S 
B 


U 
E 
B 


U 

s 
e 
r 
B 






26A 












> 






User B is informed that call has ended 


0"7 A 

d.1 A 








< 


< 






<£00 OK 


Ub_b sends ^00 UK Tor bYt 


28A 


200 OK 


IMS B forwards 200 OK response to IMS_A 


29A 






< 










<£00 OK 


lMb_A forwards the ^00 OK response to ut_A 


30A 




i 














User A is informed that call has ended 1 


22B 












< 






User B ends call 


23B 






< 


< 


< 






BYE 


UE_B releases the call with BYE 


24B 


BYE 


IMS_B forwards BYE to IMS_A 


25B 


BYE 


IMS_A forwards BYE to UE_A 


26B 




< 














User A is informed that call has ended 


27B 






» 


» 


> 






200 OK 


UE_A sends 200 OK for BYE 


28B 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


29B 


200 OK 


IMS_B forwards the 200 OK response to UE_B 


30B 












) 






User B is informed that call has ended 



4.4.2.1 .3 UC_02_R: SIP Call Flow "Normal Call" with CF ROAM CALL 

The expected call flow sequence when user A calls user B in a roaming scenario is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


1 


1 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









10 



11 



12 



13 



14 



15 



16 



17 



19 



20 



User A calls User B 



INVITE 



100 Trying 



UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards the INVITE to IMS A 



100 Trying 



INVITE 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards the INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A 



180 Ringing 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



IMS_A forwards 180 Ringing response to 
IMS B 



180 Ringing 



IMS_B forwards the 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



200 OK 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 
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Step 


Direction 


Message 


Comment 


21 


I 

j 

e 
i 
/ 


J 

j 

\ 

4- 


I 

E 

/ 


J 


I 

c 

e 
i 
E 


J 

j 

5 


L 
E 
E 


J 

5 


l\ 
c 

/ 


II 
V 


l\ 
( 

E 


n 
i 




User A is informed that call has been answered 


22 
















ACK 


UE_A acknowledges the receipt of 200 OK for 
INVITE 






7 


23 












7 

< 




ACK 


IMS A forwards ACK to 1Mb B 


24 


ACK 


IMSB forwards ACK to IMb A 


25 


ACK 


IMb A forwards ACK to UEB 


26 



















User B is informed that the call is established 


27A 




V 

7 














User A ends call 


28A 












7 

< 




BYE 


UE_A releases the call with BYE 






7 

< 


29A 


BYE 


IMS_A forwards BYE to IMS_B 


30A 


BYE 


IMS_B forwards BYE to IMS_A 


31A 
32A 


BYE 


IMS_A forwards BYE to UE_B 

User B is informed that call has ended 


33A 








< 


> 


* 

< 




200 OK 


UE B sends 200 OK for BYE 


34A 


O A A /"MX 

200 OK 


IMb A forwards 200 OK response to IMb B 


35A 


200 OK 


IMb_B forwards the 200 OK response to IMb_A 


36A 


200 OK 


IMb_A forwards the 200 OK response to UE_A 








37A 


















User A is informed that call has ended 


27B 








> 










User B ends call 


28B 










7 


7 

< 




BYE 


UE_B releases the call with BYE 


29B 


BYE 


IMS_A forwards BYE to IMS_B 


30B 


BYE 


IMS_B forwards BYE to IMS_A 


31B 
32B 


BYE 


IMS_A forwards BYE to UE_A 

User A is informed that call has ended 


< 






33B 




« 








7 

< 




200 OK 


UE_A sends 200 OK for BYE 






7 

< 


34B 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


35B 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 


36B 


200 OK 


IMS_A forwards the 200 OK response to UE_B 


37B 








i 










User B is informed that call has ended 



The test sequence and expected call flow sequence when user B calls user A in a roaming scenario is: 



Step 


Action 


CF ROAMCALL 


1 


User B calls User A 


Step 1 


2 


User A is informed of incoming call of User B 


Step 1 


3 


User B is informed that UE_A is ringing 


Step 1 5 


4 


User A answers call 


Step 1 6 


5 


User B is informed that call has been answered 


Step 21 


6 


User A is informed that the call is established 


Step 26 


7A 


User A ends call 


Step 27A 


7B 


User B ends call 


Step 27B 


8A 


User B is informed that call has ended 


Step 32A 


8B 


User A is informed that call has ended 


Step 32B 


9A 


User A is informed that call has ended 


Step 37A 


9B 


User B is informed that call has ended 


Step 37B 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









10 

11 



12 



13 



14 



15 
16 
17 

l8~ 
19 
20 
21 

~22~ 

"23" 
24 
25 
26 



27A 
28A 
29A 
30A 
31A 
32A 
33A 
34A 
35A 
36A 
37A 



User B calls User A 



INVITE 



UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_B supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



INVITE 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards the INVITE to IMS A 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards the INVITE to UE A 



100 Trying 



UE_A optionally responds with a 100 Trying 
provisional response 



User A is informed of incoming call of User B 



180 Ringing 



UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_A forwards 180 Ringing response to 
IMS B 



180 Ringing 



IMS_B forwards the 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE B 



User B is informed that UE_A is ringing 



User A answers call 



200 OK 



UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_B 



User B is informed that call has been answered 



ACK 



UE_B acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to IMS A 



ACK 



IMS A forwards ACK to UE A 



User A is informed that the call is established 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to IMS A 



BYE 



IMS A forwards BYE to UE B 



User B is informed that call has ended 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has ended 



27B 
28B 
29B 
30B 
31B 



User B ends call 



BYE 



UE B releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to IMS A 



BYE 



IMS A forwards BYE to UE A 
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Clan 
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Direction 


Message 


uomrnent 
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s 
e 
r 

A 


U 
E 
A 


U 
s 
e 
r 
B 


U 
E 
B 


I 

M 

S 
A 


I 

M 
S 
B 






33B 








< 


> 






200 OK 


UE_A sends 200 OK for BYE 


34B 


> 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


35B 


< 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 


36B 


< 


200 OK 


IMS_A forwards the 200 OK response to UE_B 



4.4.3 User-initiated call hold and resume 

UE_A places an IMS VoIP call to UE_B. Once the media path is established: 

a) The originating user puts the call on hold, stopping the media stream. The originating user then resumes the 
call. 

b) The terminating user puts the call on hold, stopping the media stream. The terminating user then resumes the 
call. 

The call flow path and node configuration for this use case corresponds to CF_INT_CALL in case of interworking and 
CF_ROAM_CALL in case of roaming. 

Depending on the UE this feature may be implemented either using relNVITE or UPDATE where UPDATE is only an 
optional feature for the UE. However, an IMS shall be able to process UPDATE requests as they may be received when 
inter working with a PSTN. 

4.4.3.1 User-initiated call hold and resume using relNVITE 
4.4.3.1.1 Description 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF_INT_CALL 


CF ROAM CALL 


1 


User A calls User B 


1 


1 


2 


User B is informed of incoming call of User A 


8 


10 


3 


User A is informed that UE B is ringing 


12 


15 


4 


User B answers call 


13 


16 


5 


User A is informed that call has been answered 


17 


21 


6 


User B is presented that call is established 


27 


26 


7A 


User A puts call on hold 


22A 


27A 


7B 


User B puts call on hold 


22B 


27B 


8A 


User B is informed that call on hold 


29A 


36A 


8B 


User A is informed that call on hold 


29B 


36B 


9A 


User A resumes call 


36A 


45A 


9B 


User B resumes call 


36B 


45B 


10A 


User B is informed that call is resumed 


43A 


54A 


10B 


User A is informed that call is resumed 


43B 


54A 


11 A 


User A is informed that call is resumed 


47A 


59A 


1 1 B 


User B is informed that call is resumed 


47B 


59B 


12 


User A ends call 


51 


64 


13 


User B is informed that call has ended 


55 


69 


14 


User A is informed that call has ended 


59 


73 
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4.4.3.1 .2 UC_03_I: SIP Call Flow "call hold and resume" using relNVITE with 

CF INT CALL 



The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



10 



11 



12 



13 



14 



15 



16 



17 



19 



20 



21 



User A calls User B 



INVITE 



100 Trying 



UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



180 Ringing 



User B is informed of incoming call of User A 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



200 OK 



UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 



ACK 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



User B is presented that call is in progress 



22A 



23A 



24A 



25A 



26A 



27A 



28A 



29A 



30A 



31A 



32A 



33A 



34A 



35A 



36A 



User A puts call on hold 



INVITE 



UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



100 Trying 



INVITE 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed that call is on hold 



200 OK 



200 OK 



UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



ACK 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



User A resumes call 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



37A 



38A 



39A 
40A 

41A 
42A 

43A 
44A 

45A 
46A 
47A 
48A 

49A 
50A 



INVITE 



UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed that call is resumed 



200 OK 



200 OK 



UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is resumed 



ACK 



UE_A acknowledges the receipt of 200 OK for 
relNVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



22B 
23B 



24B 



25B 
26B 

27B 
28B 

29B 
30B 

31B 
32B 
33B 

34B 
35B 
36B 
37B 



38B 



39B 
40B 

41B 
42B 

43B 
44B 

45B 
46B 
47B 



User B puts call on hold 



INVITE 



UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to IMS A 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to UE A 



100 Trying 



UE_A optionally responds with a 100 Trying 
provisional response 



200 OK 



200 OK 



User A is informed that call is on hold 
UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to UE_B 



ACK 



UE_B acknowledges the receipt of 200 OK for 
relNVITE 



ACK 



IMS B forwards ACK to IMS A 



ACK 



IMS A forwards ACK to UE A 



User B resumes call 



INVITE 



UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to IMS A 



100 Trying 



INVITE 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to UE A 



100 Trying 



UE_A optionally responds with a 100 Trying 
provisional response 



User A is informed that call is resumed 



200 OK 



UE_A responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to UE_B 



User B is informed that call is resumed 
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Step 



Direction 



Message 



Comment 
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M 


E 


s 
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A 










B 



48B 



49B 
50B 



ACK 



UE_B acknowledges the receipt of 200 OK for 
relNVITE 



ACK 



IMS B forwards ACK to IMS A 



ACK 



IMS A forwards ACK to UE A 



51 
52 
53 
54 
55 
56 
57 
58 
59 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to UE B 



200 OK 



User Bis informed that call has ended 



UE B sends 200 OK for BYE 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has ended 



4.4.3.1 .3 UC_03_R: SIP Call Flow "call hold and resume" using relNVITE with 

CF ROAM CALL 



The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


1 


1 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









10 



11 



12 



13 



14 



15 



16 



17 



19 



20 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to IMS A 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_A forwards 180 Ringing response to 
IMS B 



180 Ringing 



IMS_B forwards the 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



200 OK 



UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 
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Step 


Direction 


Message 


Comment 


21 
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J 


I 

c 

e 
i 
E 


J 

j 

5 


I 
E 
E 


J 

5 


l\ 

c 

/ 


II 


l\ 

E 
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User A is informed that call has been answered 


22 












* 

< 




ACK 


UE_A acknowledges the receipt of 200 OK for 
INVITE 






> 

< 


23 


ACK 


IMS A forwards ACK to IMS B 


24 


ACK 


IMS_B forwards ACK to IMS_A 


25 


ACK 


IMS_A forwards ACK to UE_B 


26 








< 










User B is presented that call is established 


27A 




» 














User A puts call on hold 


£OA 












* 

< 

< 

* 




1 N V 1 1 1 


UE_A sends relNVITE message indicating 
mprlip attrihutp "^pnrlonlv" Holrh 

III^UICl QLlllt-'ULC CICI IUUI IIV Iv^GMI 1 IUIU 1 






> 


29A 


100 Trying 


IMS_A responds with a 100 Trying provisional 

1 Co|JVJI IOC 


< 




< 

» 


30A 


INVITE 


IMS_A forwards INVITE to IMS_B 


31A 


100 Trying 


IMS_B responds with a 100 Trying provisional 

1 Co|JUI IOC 


32A 


INVITE 


IMS B forwards INVITE to IMS A 


33A 


100 Trying 


IMS_A responds with a 100 Trying provisional 

1 copui IOC 


34A 


INVITE 


IMS_A forwards INVITE to UE_B 


35A 


1 00 Trying 


UE B optionally responds with a 100 Trying 
provisional response 


36A 








< 










User B is informed that call is on hold 


37A 










> 


J 

< 

> 

< 




200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 


38A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


39A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 


40A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 


< 






41A 


ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 






> 

< 


42A 


ACK 


IMS_A forwards ACK to IMS_B 


43A 


ACK 


IMS_B forwards ACK to IMS_A 


44A 


ACK 


IMS_A forwards ACK to UE_B 


45A 




» 
















4oA 












* 

< 

< 

J 




INVITE 


UE_A sends relNVITE message indicating 
mprlip attrihntp "^pnrlrprv" fOpll Rp^iiitip^ 

1 1 ICUIa d L LI IUU LC OC 1 IU 1 CO V ^ual 1 1 ICOUI 1 ICj 






» 


47A 


100 Trying 


IMS_A responds with a 100 Trying provisional 

1 UOUUI IOC 


< 




< 

» 


48A 


INVITE 


IMS_A forwards INVITE to IMS_B 


49A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 


50A 


INVITE 


IMS_B forwards INVITE to IMS_A 


51A 


100 Trying 


IMS_A responds with a 100 Trying provisional 

1 CO^JUI IOC 


52A 


INVITE 


IMS A forwards INVITE to UE B 


53A 

C A A 


100 Trying 


UE B optionally responds with a 100 Trying 

provisional response 

User B is informed that call is resumed 


S4A 

55A 








< 


> 


* 

< 




200 OK 


UE_B responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 


56A 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


57A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 


58A 
59A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 
User A is informed that call is resumed 


< 






60A 




< 








J 

< 




ACK 


UE A acknowledges the receipt of 200 OK for 
relNVITE 






> 


61A 


ACK 


IMS_A forwards ACK to IMS_B 


62A 


ACK 


IMS_B forwards ACK to IMS_A 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









63A 



27B 
28B 

290 
B 
30B 
31B 



32B 
33B 

34B 
35B 

36B 
37B 

38B 
39B 
40B 
41B 

42B 
43B 
44B 
45B 
46B 



47B 



48B 
49B 

50B 
51 B 

52B 
53B 

54B 
55B 

56B 
57B 
58B 
59B 
60B 

61B 
62B 
63B 



ACK 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



IMS_A forwards ACK to UE_B 

UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards INVITE to IMS A 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to UE A 



UE_A optionally responds with a 100 Trying 
provisional response 



User A is informed that call is on hold 



UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_B 



UE_B acknowledges the receipt of 200 OK for 
relNVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS B 



IMS A forwards ACK to UE A 



User B resumes call 



UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards INVITE to IMS A 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to UE A 



UE_A optionally responds with a 100 Trying 
provisional response 



User A is informed that call is resumed 



UE_A responds to relNVITE with 200 OK 
indicating media attribute "sendrecv" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_B 



User B is informed that call is resumed 



UE_B acknowledges the receipt of 200 OK for 
relNVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE A 



64 
65 
66 
67 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to IMS B 
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Step 



Direction 



Message 



Comment 
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B 
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68 
69 
70 
71 

~72~ 
73 
74 



BYE 



IMS B forwards BYE to UE B 



User B is informed that call hs 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has ended 



4.4.3.2 User-initiated call hold and resume using UPDATE 
4.4.3.2.1 Description 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF INT CALL 


CF ROAM CALL 


1 


User A calls User B 


1 


1 


2 


User B is informed of incoming call of User A 


8 


10 


3 


User A is informed that UE_B is ringing 


12 


15 


4 


User B answers call 


13 


16 


5 


User A is informed that call has been answered 


17 


21 


6 


User B is informed that call is established 


21 


26 


7A 


User A puts call on hold 


22A 


27A 


7B 


User B puts call on hold 


22B 


27B 


8A 


User B is informed that call on hold 


26A 


32A 


8B 


User A is informed that call on hold 


26B 


32B 


9A 


User A resumes call 


30A 


37A 


9B 


User B resumes call 


30B 


37B 


10A 


User B is informed that call is resumed 


34A 


42A 


10B 


User A is informed that call is resumed 


34B 


42B 


1 1 A 


User A is informed that call is resumed 


38A 


47A 


11 


User A is informed that call is resumed 


38B 


47B 


12 


User A ends call 


39 


48 


13 


User B is informed that call has ended 


43 


53 


14 


User A is informed that call has ended 


47 


58 



4.4.3.2.2 UC_04_I: SIP Call Flow "call hold and resume" using UPDATE with 

CF INT CALL 



The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



100 Trying 



INVITE 



IMS_AW responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 
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Step 



Direction 



Message 



Comment 
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B 


e 


r 
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A 










B 



10 



11 



12 
T3~ 
14 

!5~ 
16 
17 



19 
20 
21 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



200 OK 



UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 



ACK 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



User B is informed that call is established 



22A 
23A 

24A 
25A 
26A 
27A 

28A 
29A 
30A 
31A 

32A 
33A 
34A 
35A 

36A 
37A 
38A 



22B 
23B 

24B 
25B 
26B 
27B 

28B 
29B 
30B 



User A puts call on hold 



UPDATE 



UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 



UPDATE 



IMS A forwards UPDATE to IMS B 



UPDATE 



IMS B forwards UPDATE to UE B 



200 OK 



User B is informed that call is on hold 
UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A resumes call 



UPDATE 



UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 



UPDATE 



IMS A forwards UPDATE to IMS B 



UPDATE 



IMS B forwards UPDATE to UE B 



User B is informed that call is resumed 



200 OK 



UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is resumed 



User B puts call on hold 



UPDATE 



UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 



UPDATE 



IMS B forwards UPDATE to IMS A 



UPDATE 



IMS A forwards UPDATE to UE A 



User A is informed that call on hold 



200 OK 



UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to UE_B 



User B resumes call 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



31B 



32B 
33B 
34B 
35B 

36B 
37B 
38B 



UPDATE 



UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 



UPDATE 



IMS B forwards UPDATE to IMS A 



UPDATE 



IMS A forwards UPDATE to UE A 



User A is informed that call is resumed 



200 OK 



UE_A responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to UE_B 



User B is informed that call is resumed 



39 
40 
41 

~42~ 
"43" 
44 
45 
46 
47 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has ended 



4.4.3.2.3 UC_04_R: SIP Call Flow "call hold and resume" using UPDATE with 

CFROAMCALL 

The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


1 


1 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









10 



11 



12 



13 



14 



15 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards the INVITE to IMS A 



100 Trying 



INVITE 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards the INVITE to UE B 



100 Trying 
180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



UE_B optionally responds with a 100 Trying 
rovisional response 

UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



IMS_A forwards 180 Ringing response to 
IMS B 



IMS_B forwards the 180 Ringing response to 
IMS A 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









16 
17 



19 
20 
21 

~22~ 

~23~ 
24 

~25~ 
26 



User B answers call 



200 OK 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 



ACK 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to IMS A 



ACK 



IMS A forwards ACK to UE B 



User B is informed that the call is established 



27A 
28A 

29A 
30A 
31A 
32A 
33A 

34A 
35A 
36A 
37A 
38A 

39A 
40A 
41A 
42A 
43A 

44A 
45A 
46A 
47A 



27B 
28B 

29B 
30B 
31B 
32B 
33B 

34B 
35B 
36B 
37B 
38B 

39B 
40B 



UPDATE 



UPDATE 



UPDATE 



UPDATE 



200 OK 



200 OK 



200 OK 



200 OK 



UPDATE 



UPDATE 



UPDATE 



UPDATE 



200 OK 



200 OK 



200 OK 



200 OK 



UPDATE 



UPDATE 



UPDATE 



UPDATE 



200 OK 



200 OK 



200 OK 



200 OK 



UPDATE 



UPDATE 



UPDATE 



User A puts call on hold 



UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to IMS A 



IMS A forwards UPDATE to UE B 



User B is informed that call is on hold 



UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



User A resumes call 



UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to IMS A 



IMS A forwards UPDATE to UE B 



User B is informed that call is resumed 



UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is resumed 

UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to IMS A 



IMS A forwards UPDATE to UE A 



User A is informed that call on hold 



UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_B 



User B resumes call 



UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to IMS A 



ETSI 



34 



ETSI TS 186 011-2 V2.2.1 (2009-03) 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









41B 
42B 
43B 

44B 
45B 
46B 
47B 



UPDATE 



IMS A forwards UPDATE to UE A 



User A is informed that call is resumed 



200 OK 



UE_A responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS B forwards 200 OK to IMS A 



200 OK 



IMS_A forwards the 200 OK response to UE_B 



User B is informed that call is resumed 



48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 



User 



AendscaN 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to IMS A 



BYE 



IMS A forwards BYE to UE B 



User B is informed that call has er 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has ended 



4.4.4 IMS message exchange between UEs in different networks 
4.4.4.1 Description 

The UE_A sends a MESSAGE to UE_B located in a different network. 



The test sequence typically associated with this use case when an established session is released is as follows (CFW 
step numbers refer the call flow step numbering): 



Step 


Action 


CF INT CALL 


CF_ROAM_CALL 


1 


User A sends an instant message 


Step 1 


Step 1 


2 


User B is informed about the instant message 


Step 5 


Step 6 


3 


Optional: User A is presented a delivery report 


Step 9 


Step 1 1 
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4.4.4.2 UC_05_I: SIP Call flow for IMS Message Exchange with CF_INT_CALL 

The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



User A sends an instant message to us< 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS A sends MESSAGE to IMS B 



MESSAGE 



IMS B sends MESSAGE to UE B 



User B is informed about the instant message 



200 OK 



UE B sends 200 OK to IMS B 



200 OK 



IMS B sends 200 OK to IMS A 



200 OK 



IMS A sends 200 OK to UE A 



4.4.4.3 



UC_05_R: SIP Call Flow for IMS Message Exchange with CF_ROAM_CALL 



The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









10 



User A sends an instant message to user B 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS A forwards MESSAGE to IMS B 



MESSAGE 



IMS B forwards MESSAGE to IMSA 



MESSAGE 



IMS A forwards MESSAGE to UE B 



200 OK 



User B is informed about the instant message 
UE_B responds with 200 OK to IMS_A 



200 OK 



IMS A forwards 200 OK to IMS B 



200 OK 



IMS B forwards 200 OK to IMS A 



200 OK 



IMS A forwards 200 OK to UE A 



4.4.5 Supplementary Service Anonymous Communication Rejection 
(ACR) 

4.4.5.1 Description 

UE_A makes an IMS VoIP call to UE_B while UE_B is roaming in IMS A. UE_A is subscribed to OIR service in 
permanent mode or default presentation restricted temporary mode, UE_B is subscribed to ACR supplementary service. 
The call flow path and node configuration for this use case corresponds to CF_ROAM_AS. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF_ROAM_AS 


1 


User A calls User B 


Step 1 


2 


User A is informed that call has been rejected due to ACR 


Step 17 
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4.4.5.2 UC_06_R: SIP message flow for SS ACR with CF_ROAM_AS 

The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


A 


I 


A 


s 


E 


s 


E 


M 


S 


M 


S 


e 


A 


e 


B 


S 


A 


S 


B 


r 




r 




A 




B 




A 




B 













10 



11 



12 



13 



14 



15 



16 



17 



19 



20 



21 



22 



User A calls User B 



INVITE 



100 Trying 



UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE_A supports 



IMS_A responds with a 100 Trying 
provisional response 



INVITE triggers the OIR IFC in IMS_A 



INVITE 



IMS A forwards the INVITE to IMS A AS 



100 Trying 



INVITE 



IMS_A AS optionally responds with a 100 
Trying provisional response 



IMS_A AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS A 



100 Trying 



IMS_A responds with a 100 Trying 
provisional response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying 
provisional response 



INVITE 



INVITE triggers the ACR IFC in IMS_B 



IMS B forwards the INVITE to IMS B AS 



100 Trying 



AS optionally responds with a 100 Trying 
provisional response 



433 

Anonymity 
Disallowed 



IMS_B AS responds with 433 Anonymity 
Disallowed to IMS B 



433 

Anonymity 
Disallowed 



IMS_B forwards the 433 Anonymity 
Disallowed to IMS A 



433 

Anonymity 
Disallowed 



IMS_A forwards the 433 Anonymity 
Disallowed to IMS A AS 



433 

Anonymity 
Disallowed 



IMS_A AS forwards, possibly modified, 
433 Anonymity Disallowed to IMS_A 



433 

Anonymity 
Disallowed 



IMS_A forwards the 433 Anonymity 
Disallowed to UE A 



User A is informed that the call has been 
rejected due to ACR 



ACK 



UE A sends ACK to IMS A 



ACK 



IMS A forwards the ACK to IMS A AS 



ACK 



IMS_A AS forwards, possibly modified, 
ACK to IMS A 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to IMS B AS 



4.4.6 Supplementary Service Outgoing Communication Barring (OCB) 
4.4.6.1 Description 

While roaming in IMS A network, UE_B places an IMS VoIP call to UE_A. UE_B is subscribed to OCB service and 
based on the UE_B identity the OCB service is invoked. The call flow path and node configuration for this use case 
corresponds to CF_ ROAM_AS. 
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The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF ROAM AS 


1 


User B calls User A 


Step 1 


2 


User B is informed that call was declined 


Step 1 1 



4.4.6.2 UC_07_R: SIP message flow for SS OCB with CF_ROAM_AS 

The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


1 


1 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B 


S 


S 


B 


r 




r 




A 


B 




A 




B 











10 



11 



12 



13 



14 



User B calls User A 



INVITE 



UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_B supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE triggers the OCB IFC in IMS_B 



INVITE 



IMS B forwards the INVITE to IMS B AS 



100 Trying 



AS optionally responds with a 100 Trying 
provisional response 



603 Decline 



IMS B AS returns 603 Decline to IMS B 



603 Decline 



IMS B forwards the 603 Decline to IMS A 



603 Decline 



IMS A forwards the 603 Decline to UE B 



ACK 



User B is informed that call was declined 
UE B sends ACK to IMS A 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to IMS B AS 



4.4.7 Supplementary Service Originating Identification Presentation (OIP) 
4.4.7.1 Description 

UE_A places an IMS VoIP call to UE_B while UE_B is roaming in IMS A network. UE_B is subscribed to OIP 
service. The call flow path and node configuration for this use case corresponds to CF_ROAM_AS. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF_ROAM_AS 


1 


User A calls User B 


Step 1 


2 


User B is informed of incoming call of User A, user A's identity is 
displayed 


Step 14 


3 


User A is informed that UE_B is ringing 


Step 21 


4 


User B answers call 


Step 22 


5 


User A is informed that call has been answered 


Step 29 


6 


User B is informed that the call is established 


Step 36 


7 


User A ends call 


Step 37 


8 


User B is informed that call has ended 


Step 44 


9 


User A is informed that call has ended 


Step 51 
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4.4.7.2 UC_08_R: SIP message flow for SS OIP with CF_ROAM_AS 

The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B 


S 


S 


B 


r 




r 




A 


B 




A 




B 











10 



11 



12 



13 



14 



15 



16 



17 



18 



19 



20 



21 



22 



23 



24 



25 



26 



27 



28 



30 



31 



32 



User A calls User B 



INVITE 



100 Trying 



UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 



INVITE 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



IMS B forwards the INVITE to IMS B AS 



AS optionally responds with a 100 Trying 
provisional response 



IMS_B AS returns, possibly modified, INVITE to 
IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards the INVITE to IMS A 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards the INVITE to UE B 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A, 
User A's identity is displayed 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



IMS_A forwards 180 Ringing response to 
IMS B 



IMS_B forwards 180 Ringing response to 
IMS B AS 



IMS_B AS forwards 180 Ringing response to 
IMS B 



IMS_B forwards the 180 Ringing response to 
IMS A 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_B AS 



IMS_B AS forwards 200 OK response to IMS_B 



IMS_B forwards the 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



ACK 



ACK 



ACK 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS B AS 
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Step 


Direction 


Message 


Comment 




U 

s 
e 
r 

A 


U 
E 
A 


U 
s 
e 
r 
B 


U 
E 
B 


1 

M 

S 
A 


1 

M 

S 
B 


A 
S 
B 






33 










i 


(. 


<: 




ACK 


IMS B AS forwards, possibly modified, ACK to 
IMS_B 


34 


ACK 


IMS B forwards ACK to IMS A 


35 


ACK 


IMS_A forwards ACK to UE_B 


36 




» 




< 












User B is informed that the call is established 


37 






User A ends call 


38 












» 

$ 


» 

< 




BYE 


UE_A releases the call with BYE 






» 

(. 


39 


BYE 


IMS_A forwards BYE to IMS_B 


40 


BYE 


IMS_B forwards BYE to IMS_B AS 


41 


BYE 


IMS B AS forwards, possibly modified, BYE to 
IMS_B 


42 


BYE 


IMS B forwards BYE to IMS A 


43 
44 


BYE 


IMS A forwards BYE to UE B 

User B is informed that call has ended 


45 








i 


> 


> 

d 


> 

< 




200 OK 


UE_B sends 200 OK for BYE 


46 


200 OK 


IMS_A forwards 200 OK response to IMS_B 


47 


200 OK 


IMS_B forwards 200 OK response to IMS_B AS 


48 


200 OK 


IMS_B AS forwards 200 OK response to IMS_B 


49 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 


50 


200 OK 


IMS_A forwards the 200 OK response to UE_A 


i 






51 




( 
















User A is informed that call has ended 



4.4.8 Supplementary Service Originating Identification Restriction (OIR) 
4.4.8.1 Description 

While roaming in IMS A network, UE_B places an IMS VoIP call to UE_A. UE_A is subscribed to OIP service, UE_B 
is subscribed to OIR service in permanent mode or default presentation restricted temporary mode. The call flow path 
and node configuration for this use case corresponds to CF_ROAM_AS. 

The test sequence typically associated with this use case is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF_ROAM_AS 


1 


User B calls User A 


Step 1 


2 


User A is informed of incoming call of User B, user B's identity is 
not displayed 


Step 18 


3 


User B is informed that UE A is ringing 


Step 27 


4 


User A answers call 


Step 28 


5 


User B is informed that call has been answered 


Step 37 


6 


User A is informed that the call is established 


Step 46 


7 


User A ends call 


Step 47 


8 


User B is informed that call has ended 


Step 56 


9 


User A is informed that call has ended 


Step 65 
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4.4.8.2 UC_09_R: SIP message flow for SS OIR with CF_ROAM_AS 

The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


A 


I 


A 


s 


E 


s 


E 


M 


S 


M 


S 


e 


A 


e 


B 


S 


A 


S 


B 


r 




r 




A 




B 




A 




B 













_4_ 
5 



10 



11 



12 



13 



14 



15 



16 



17 



20 



21 



22 



23 



24 



25 



26 



27 



28 




User B calls User A 



INVITE 



100 Trying 



UE_B sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE_B supports 



INVITE 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying 
provisional response 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



IMS B forwards the INVITE to IMS B AS 



IMS_B AS optionally responds with a 100 
Trying provisional response 



IMS_B AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS_B 



IMS_B responds with a 100 Trying 
provisional response 



IMS B forwards the INVITE to IMS A 



IMS_A responds with a 100 Trying 
provisional response 



INVITE triggers the PIP IFC in IMS_A 



IMS A forwards the INVITE to IMS A AS 



IMS A AS optionally responds with a 1 00 
Trying provisional response 



IMS_A AS returns modified INVITE 
including modified From and P-Asserted 
headers to IMS A 



IMS_A responds with a 100 Trying 

provisional response 

IMS_A forwards the INVITE to UE_A 



UE_A optionally responds with a 100 
Trying provisional response 



180 Ringing 



ed 



180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



180 Ringing 



UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started 
alerting 



IMS_A forwards the 1 80 Ringing to 
IMS A AS 



IMS_A AS forwards, possibly modified, 
180 Ringing to IMS_A 



IMS_A forwards 180 Ringing response to 
IMS B 



IMS_B forwards 180 Ringing response to 
IMS BAS 



IMS_B AS forwards, possibly modified, 
180 Ringing response to IMSJ3 



IMS_B forwards the 180 Ringing 
response to IMS_A 



IMS_A forwards the 180 Ringing 
response to UE_B 



User B is informed that UE_A is ringing 



User A answers call 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


A 


I 


A 


s 


E 


s 


E 


M 


S 


M 


S 


e 


A 


e 


B 


S 


A 


S 


B 


r 




r 




A 




B 




A 




B 













29 



30 



200 OK 



UE_A responds INVITE with 200 OK to 
indicate that the call has been answered 



200 OK 



IMS A forwards the 200 OK to IMS A AS 



31 



32 



33 



34 



351 



36 



37 



38 



39 
40 



41 



42 
~43~ 
44 

~45~ 
46 

~47~ 
"48" 
49 
50 



51 



52 
53 
54 

~55~ 
56 
57 
58 



59 



60 



61 



62 
63 



64 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



ACK 



ACK 



ACK 



ACK 



BYE 



BYE 



BYE 



BYE 



BYE 



BYE 



BYE 



BYE 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



IMS_A AS forwards, possibly modified, 
200 OK to IMS A 



IMS_A forwards 200 OK response to 
IMS B 



IMS_B forwards 200 OK response to 
IMS BAS 



IMS_B AS forwards, possibly modified, 
200 OK response to IMS_B 



IMS_B forwards the 200 OK response to 
IMS A 



IMS_A forwards the 200 OK response to 
UE B 



User B is informed that call has been 
answered 



UE_B acknowledges the receipt of 200 
OK for INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS B AS 



IMS_B AS forwards, possibly modified, 
ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards the ACK to IMS A AS 



IMS_A AS forwards, possibly modified, 
ACK to IMS A 



IMS A forwards ACK to UE A 



User A is informed that the call is 
established 



User A ends call 



UE A releases the call with BYE 



IMS A forwards BYE to IMS B 



IMS B forwards BYE to IMS B AS 



IMS_B AS forwards, possibly modified, 
BYE to IMS B 



IMS B forwards BYE to IMS A 



IMS A forwards the BYE to IMS A AS 



IMS_A AS forwards, possibly modified, 
BYE to IMS A 



IMS A forwards BYE to UE B 



User B is informed that call has er 



UE B sends 200 OK for BYE 



IMS_A forwards 200 OK response to 
IMS B 



IMS_B forwards 200 OK response to 
IMS BAS 



IMS_B AS forwards, possibly modified, 
200 OK response to IMS_B 



IMS_B forwards the 200 OK response to 
IMS A 



IMS A forwards the 200 OK to IMS A AS 



IMS_A AS forwards, possibly modified, 
200 OK to IMS A 



IMS_A forwards the 200 OK response to 
UE A 
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otep 


Direction 


Message 


Comment 




U 


U 


U 


U 






A 






A 








s 


E 


s 


E 


M 


S 


M 


S 








e 


A 


e 


B 


S 


A 


S 


B 








i 








r 






A 






B 












A 






B 


























65 




( 


















User A is informed that call has ended 



4.4.9 Supplementary Service HOLD 
4.4.9.1 Description 

UE_A places an IMS VoIP call to UE_B which places the call on HOLD. UE_A will be notified by the AS that the call 
is on hold. UE_B will resume the call, and UE_A will be informed by the AS that the call is resumed. 

The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF_ROAM_AS 


1 


User A calls User B 


1 


2 


User B is informed of incoming call of User A 


10 


3 


User A is informed that UE B is ringing 


15 


4 


User B answers call 


16 


5 


User A is informed that call has been answered 


21 


6 


User B is informed that call is established 


26 


7 


User B puts call on hold 


27 


8 


User A is informed that call on hold with AS tone 


40 


9 


User B is informed that call on hold 


47 


10 


User B resumes call 


54 


11 


User A is informed that call is resumed 


67 


12 


User B is informed that call is resumed 


81 


13 


User A ends call 


82 


14 


User B is informed that call has ended 


86 


15 


User A is informed that call has ended 


91 



4.4.9.1.1 



UC_10_R: SIP Call Flow "call hold and resume with AS tone" using relNVITE 
with CF ROAM AS 



The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B 


S 


S 


B 


r 




r 




A 


B 




A 




B 











3 

~4~ 
~5~ 
~6~ 
7 

IT 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



Jser A calls User B 



UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE_A supports 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying 
provisional response 



IMS B forwards INVITE to IMS A 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards INVITE to UE B 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B 


S 


S 


B 


r 




r 




A 


B 




A 




B 











10 



11 



12 



100 Trying 



UE_B optionally responds with a 100 
Trying provisional response 



User B is informed of incoming call of 
User A 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started 
alerting 



180 Ringing 



IMS_A forwards 180 Ringing response to 
IMS B 



13 
14 

~T5~ 

TeT 

17 

~T8~ 
19 

~20~ 

21 

22 
~23~ 
~24~ 
~25~ 
~26~ 



28 



29 



30 



31 



32 



33 



35 



35 



36 



37 



38 



180 Ringing 



180 Ringing 



200 OK 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



IMS_B forwards the 180 Ringing response 
to IMS A 



IMS_A P- forwards the 180 Ringing 
response to UE_A 



User A is informed that UE_B is ringing 



User B answers call 

UE_B responds to INVITE with 200 OK to 
indicate that the call has been answered 



IMS_A forwards 200 OK response to 
IMS B 



IMS_B forwards 200 OK response to 
IMS A 



IMS_A forwards the 200 OK response to 
UE A 



User A is informed that call has been 
answered 



UE_A acknowledges the receipt of 200 
OK for INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE B 



User B is informed that call is established 



User B puts call on hold 



UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying 
provisional response 



IMS B sends relNVITE to AS B 



AS_B optionally responds with a 100 
Trying provisional response 



AS B sends relNVITE to IMS B 



IMS_B responds with a 100 Trying 
provisional response 



IMS B forwards relNVITE to IMS A 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards relNVITE to UE A 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B 


S 


S 


B 


r 




r 




A 


B 




A 




B 











39 




42 



43 



100 Trying 



UE_A optionally responds with a 100 
Trying provisional response 



User A is informed that call is on hold with 
AS tone 



200 OK 



200 OK 



UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 



IMS_A forwards 200 OK response to 
IMS B 



200 OK 



IMS_B forwards 200 OK response to 
AS B 



44 



45 



46 




49 



50 



51 



52 



53 



54 



55 



56 



57 



58 



59 



60 



61 



62 



63 



64 



65 



66 



67 



68 



69 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



ACK 



ACK 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



200 OK 



AS_B forwards 200 OK response to 
IMS B 



IMS_B forwards 200 OK response to 
IMS A 



IMS A forward the 200 OK to UE B 



UE_B acknowledges the receipt of 200 
OK for relNVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to AS B 



AS B forwards ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE A 



User B resumes call 



UE B sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 



IMS_A responds with a 100 Trying 
provisional response 



IMS A sends relNVITE to IMS B 



IMS_B responds with a 100 Trying 
provisional response 



IMS B sends relNVITE to AS B 



AS_B optionally responds with a 100 
Trying provisional response 



AS B forwards INVITE to IMS B 



IMS_B responds with a 100 Trying 
provisional response 



IMS B sends relNVITE to IMS A 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards relNVITE to UE A 



UE_A optionally responds with a 100 
Trying provisional response 



User A is informed that call is resumed 



UE A sends the 200 OK indicating media 
attribute "sendrecv" to IMS A 



IMS_A forwards 200 OK response to 
IMS B 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B 


S 


S 


B 


r 




r 




A 


B 




A 




B 











70 



71 



72 



73 



74 



200 OK 



200 OK 



200 OK 



200 OK 



IMS_B forwards 200 OK response to 
AS B 



AS B forwards the 200 OK for INVITE 



IMS B forwards 200 OK to IMS A 



IMS A forwards 200 OK to UE B 



User B is informed that call is resumed 



75 

~76~ 

~tT 

"78" 
~79~ 
~W 
"8T 
~82~ 
~83~ 
~84~ 
~85~ 
~86~ 
~87~ 
"88~ 
"89" 
90 
"9T 



ACK 



ACK 



ACK 



ACK 



ACK 



ACK 



ACK 



BYE 



BYE 



BYE 



200 OK 



200 OK 



200 OK 



200 OK 



UE B sends ACK to IMS A 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to AS B 



AS B forwards ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE A 



User A is informed that call resumed 



User A ends call 



UE A releases the call with BYE 



IMS A forwards BYE to IMS B 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



UE B sends 200 OK for BYE 



IMS_A forwards 200 OK response to 
IMS B 



IMS_B forwards 200 OK response to 
IMS A 



IMS_A forwards the 200 OK response to 
UE A 



User A is informed that call has ended 



4.4.10 Supplementary Service Call Forward Unconditional (CFU) 
4.4.10.1 Description 

UE_A places an IMS VoIP call to UE_B which has CFU activated towards user UE_B2 which is located in IMS_A. 
UE_A may be notified by the AS that the call is forwarded. UE_B2 answers the call without previous ringing 
indication. The call is released by UE_A. 
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The test sequence typically associated with this use case when is as follows (CFW step numbers refer the call flow step 
numbering): 



Step 


Action 


CF_ROAM_AS 


1 


User A calls User B 


1 


2 


User A may be informed of call diversion 


11 


3 


User B2 answers call 


19 


4 


User A is informed that call has been answered 


26 


6 


User B2 is informed that call is established 


32 


7 


User A ends call 


33 


8 


User B2 is informed that call has ended 


37 


9 


User A is informed that call has ended 


42 



4.4.1 0.1 .1 UC_1 1_R: SIP Call Flow "Communication Forwarding unconditional" with 

CF ROAM AS 



The expected call flow sequence is: 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


1 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B2 


S 


S 


B 


r 




r 




A 


B 




A 




B2 











10 



11 



12 



13 



14 



15 



16 



17 



18 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



181 Call is 

being 

forwarded 



181 Call is 

being 

forwarded 



181 Call is 

being 

forwarded 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE_A supports 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying 
provisional response 



INVITE triggers the CFU IFC in IMS_B 



IMS B forwards the INVITE to AS B 



AS_B optionally responds with the 100 
Trying to IMS_B 



AS_B applies the CDIV CFU procedure 



AS_B indicates optionally to IMS_B that 
call has been forwarded 



IMS_B indicates to IMS_A that call has 
been forwarded 



IMS_A indicates that call to UE_B has 
been forwarded 



User A may be informed of call diversion 



AS_B returns modified INVITE including 
new request URI and history header to 
IMS B 



IMS_B responds with a 100 Trying 
provisional response 



IMS B forwards the INVITE to IMS A 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards the INVITE to UE B2 



UE_B2 optionally responds with a 100 
Trying provisional response 



User B2 is informed of incoming call of 
User A 
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Step 


Direction 


Message 


Comment 




U 

s 
e 
r 
A 


U 
E 
A 


U 

s 
e 
r 

B2 


U 
E 

B2 


I 

M 

S 
A 


1 

M 
S 
B 


A 
S 
B 






20 










* 


> 

< 


> 

< 




200 OK 


UE B2 responds to INVITE with 200 OK 
to indicate that the call has been 
answered 


21 


200 OK 


IMS_A forwards 200 OK response to 
IMS B 


22 


200 OK 


IMS_B forwards 200 OK response to 
AS B 


23 


200 OK 


AS_B returns, possibly modified, 200 OK 
to IMS B 


24 


200 OK 


IMS_B forwards 200 OK response to 
IMS A 


nc 
£0 


^UU Ul\ 


IMS A forwards 200 OK response to 
UE A 


< 






26 




< 
















User A is informed that call has been 


27 












> 


» 

< 




ACK 


UE A acknowledges the receipt of 200 
OK for INVITE 






7 


28 


ACK 


IMS_A forwards ACK to IMS_B 




AUK 


IMb B forwards AOK to Ab_B 


30 


ACK 


AS B returns, possibly modified, ACK to 
IMS B 


31 


ACK 


IMS_B forwards ACK to UE_B2 


< 






oo 
33 




* 




< 












User B2 is informed that call is 

established 

User A ends call 


34 












» 






BYE 


UE_A releases the call with BYE 






» 


35 


BYE 


IMS A forwards BYE to IMS B 


36 
37 


BYE 


IMS_B forwards BYE to UE_B 

User B is informed that call has ended 


< 




38 








< 


» 


> 

< 






200 OK 


UE B sends 200 OK for BYE 


oy 


onn cw 
<L\J\J Ul\ 


IMo A TOrWaruS cSjKj Ur\ rGSpOnSG TO 

IMS B 


40 


200 OK 


IMS B forwards 200 OK response to 
IMS A 


41 


200 OK 


IMS A forwards the 200 OK response to 
UE A 


< 
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4.4.10.1.2 



UC_12: SIP Call Flow "Normal Call" with 2 UEs registered to same public identity 



The test sequence and expected call flow sequence when user A calls user B with 2 UEs, i.e. UE_B1 and UEB2, in an 
interworking scenario is: 





Mciiun 


PC IMT PAI 1 


I 




olep I 


O 
c. 


1 loof D ] o inf/MTnQrl t~\\ inr»nminn coll 1 Ipqk A r\v\ 1 IC B^ 
Uocl D lb INlUi illfcJU Ul IllOUlIllliy Od.ll Ul Uocl M UN UC D 1 


Q+Qn ft 
oiup o 


3 


1 l^pr R \gl infnrmprl nf inpnminn opII of I l^pr A on 1 IF R? 


Step 8 


4 


User A is informed that a UE of User B is ringing 


Step 12 j 


5 


User B answers call on UE B2 


Step 13 


6 


User B is informed at UE B1 that the call is no longer offered 


Step 21 


7 


User A is informed that call has been answered 


Step 17 


8 


User B is informed that the call is established 


Step 21 


9A 


User A ends call 


Step 22A 


9B 


User B ends call 


Step 22B 


10A 


User B is informed that call has ended 


Step 26A 


10B 


User A is informed that call has ended 


Step 26B 


11A 


User A is informed that call has ended 


Step 30A 


1 1 B 


User B is informed that call has ended 


Step 30B 



Note that steps 6 and 7 may happen in different order. 



Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



10 



11 



12 



13 



14 



15 



16 



17 



19 



20 



INVITE 



User A calls User B 

UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



100 Trying 



INVITE 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



100 Trying 



INVITE 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards INVITE to UE B1 



100 Trying 



UE_B1 optionally responds with a 100 Trying 
provisional response 



User B is informed on UE_B1 of incoming call of 
User A 



180 Ringing 



UE_B1 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that a UE of User B is ringing 



INVITE 



IMS B forwards INVITE to UE B2 



100 Trying 



UE_B2 optionally responds with a 100 Trying 
provisional response 



User B is informed on UE_B2 of incoming call of 
User A 



180 Ringing 



UE_B2 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_B forwards 2 nd 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 2 nd 180 Ringing response 
to UE A 



User B answers call at UE B2 



200 OK 



UE_B2 responds to INVITE with 200 OK to 
indicate that the call has been answered 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



21 

~22~ 



23 



24 
"25" 
26 
27 

~28~ 
29 
30 



CANCEL 



IMS_B sends CANCEL request to UE_B1 



200 OK 



200 OK 



UE_B1 sends 200 OK response to the CANCEL 

request to IMS_B 

UE_B1 informs user B that the call is no longer 
offered to this UE and stops ringing 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



ACK 



ser A is informed that call has been answered 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



User B is informed that the call is established 



31A 

32A 
33A 
34A 
35A 
36A 
37A 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



38A 
39A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has ended 



31B 
32B 
33B 
34B 
35B 
36B 
37B 
38B 
39B 



User B ends call 



BYE 



UE B releases the call with BYE 



BYE 



IMS B forwards BYE to IMS A 



BYE 



IMS A forwards BYE to UE A 



User A is informed that call has ended 



200 OK 



UE A sends 200 OK for BYE 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to UE_B 



User B is informed that call has ended 



Note that the call flow sequence steps 6 through 12 and 13 through 18 may occur in an interleaved fashion. In addition, 
steps 21 through 23 and steps 24 through 26 may also occur in an interleaved fashion. 



4.5 Test Descriptions 

This clause introduces interoperability test descriptions (TDs) which realize one or more IMS NNI test purposes of 
TS 186 011-1 [2]. 

Each TD is defined on the basis of one of the generic use cases forms presented in the previous clause. Each test 
sequence step in a TD includes also a reference to a specific call flow step of the generic use case. Call flow steps which 
are associated with the test body are repeated after each TD and include any modifications necessary to adapt the 
generic use case. In the adapted call flow steps that are associated with user interactions are shown shaded and steps 
which have pass criteria are associated with are shown in bold. 

Note that the expected test sequence may only show the Call Flow that affects the test. 
In the tabulations which follow, all references are to ES 283 003 [1]. 
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4.5.1 General Capabilities 

4.5.1 .1 SIP messages longer than 1 500 bytes 



Interoperability Test Description 


Identifier: 


TD IMS 0001 


Summary: 


IMS network shall support SIP messages greater than 1 500 bytes 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 




TP IMS 4002 1 


ES 283 003 [1], clause 4.2A V 


Use Case ref.: 


UC_05J 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A and IMS_A configured to use TCP for transport 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered user of IMS B using any user identity 



Test Sequence: 


Step 






1 




User A sends message to User B with at least 1 500 characters 




2 


Verify that user B receives message from user A 








Conformance 


Check 




Criteria: 


1 


TP_IMS_4002_01 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 

containing a Message Body greater than 1 300 bytes } 
then { IMS_B receives the MESSAGE 

containing the Message Body greater than 1 300 bytes } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



User A sends an instant message to user B 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS_A sends MESSAGE to IMS_B with via 
header indicating TCP 



MESSAGE 



IMS B sends MESSAGE to UE B 



User B is informed about the instant message 



200 OK 



UE B sends 200 OK to IMS B 



200 OK 



IMS B sends 200 OK to IMS A 



200 OK 



IMS A sends 200 OK to UE A 



Optional: User A is presented a delivery report 
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Registration and De-registration 



2.1 



First time registration in a visited IMS network 



Interoperability Test Description 


lucnii i ici . 


TD IMS 0002 


Summary: 


First time registration in a visited IMS network 


Configuration: 


CF ROAM REG 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5011 01 


ES 283 003 [1], clause 5.2.2 %2 


TP IMS 5011 02 


ES 283 003 [1], clause 5.2.2 \2 


TP IMS 5044 01 


ES 283 003 [1], clause 5.2.3 V 


TP IMS 5089 01 


ES 283 003 [1], clause 5.4.1.2.1 1J6 


TP IMS 5092 01 


ES 283 003 [1], clause 5.4.1 .2.2 1f1 


TP IMS 5096 01 


ES 283 003 [1], clause 5.4.2.1.1 V 


Use Case ref.: 


UC 01 R 



Pre-test 
conditions: 



Test Sequence: 



HSS of IMS_B is configured according to table 1 

UE_B IP bearers established to IMS_A as per clause 4.2.1 

UE_B not registered in IMS_B 

IMS_A within the trust domain of IMS_B 

UE_B is configured to use AKA authentication 



Step 



User B registers in IMS B using any valid user identity 



Verify that UE_B shows successful registration 



Conformance 
Criteria: 



Check 



1 



TP_IMS_501 1_01 in CFW step 3 (REGISTER): 
ensure that { 

when { UE_B sends an unprotected REGISTER to IMS_A 

containing a Security-Client_header } 
then { IMS_A sends the REGISTER to IMS_B 
containing a Path_header 

containing P-CSCF_SIP_URI of IMS_A and 
containing a Require_header 

containing a path_option_tag and 
containing a P-Charging-Vector_header 

containing an icidjparameter and 
containing a Authorization_header 
containing an integrity-protected_parameter 
indicating no 
not containing a Security-Verify_header and 
not containing a Security -Client_header and 
containing a P-Visited-Network-ID_header 
indicating "the visited network at the home network" } 
1 
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Interoperability Test Description 




2 


TP_IMS_501 1_02 in CFW step 7 (REGISTER): 
ensure that { 

when { UE_B sends a protected REGISTER to IMS_A 

containing a Security-Client header } 
then { IMS_A sends the REGISTER to IMS_B 
containing a Path header 

containing P-CSCF_SIP_URI of IMS_A and 
containing a Requirejneader 

containing a path_option_tag and 
containing a P-Charging-Vector_header 

containing an icidjparameter and 
containing a Authorization_header 

containing an integrity-protected_parameter 
indicating yes 
not containing a Security-Verify _header and 
not containing a Security-Client_header and 
containing a P-Visited-Network-ID_header 

indicating "the visited network at the home network"} 

} 


3 


TP_IMS_5044_01 in CFW step 10 (SUBSCRIBE): 
ensure that { 

when { IMS A receives a 200 response from IMS B 
} 

then { IMS_A sends a SUBSCRIBE to IMS_B 
containing a Request_URI 
indicating "the resource to which the P-CSCF wants 
to subscribe to" and 
containing a From header 
indicating P-CSCF_SIP_URI of IMS_A and 
containing a To_header 

indicating the default_public_user_identity of UE B and 
containing an Eventjneader 
indicating the reg_event_package and 
containing an Expires_header 
set to "a value greater than the one in the Expires_header 
of the 200_response" and 
containing a P-Asserted-ldentity header 

set to the P-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
containing an icid parameter } 

} 


4 


TP_IMS_5089_01 in CFW step 4 (401 Unauthorized): 
ensure that { 

when { UE B sends an initial REGISTER to IMS B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 
(not containing an integrity-protected _parameter or 

containing an integrity-protectedjparameter indicating no) } 
then { IMS_B sends a 401_response to IMS_A 
containing an WWW-Authenticate_header 
containing a realmjparameter 

indicating the operator Jdentitier of IMS_B and 
containing a nonce jparameter 
(containing a RAND jparameter and 
containing an AUTN_parameter) and 
containing an algorithmjparameter 

indicating AKAv1-MD5 and 
containing an ik parameter and 
containing a ck parameter } 

} 
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Interoperability Test Description 




5 


TP_IMS_5092_01 in CFW step 8 (200 Ok): 
ensure that { 

when { UE B sends a protected REGISTER to IMS B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 

containing an integrity-protected_parameter indicating yes } 
then { IMS_B sends 200_response to IMS_A 

containing the same Path_header as in the protected REGISTER 

and 

containing a P-Associated-URI_header 
containing all registered_public_identities and "its 
associated set of implicitly registered public user identities" 

indicating (first the default_public_user_identity and 

no barred_public_user_identities) and 
containing a Service-Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a Contact_header 

indicating "all contact addresses" 

for the default _public user identity of UE Bj 

} 


6 


TP_IMS_5096_01 in CFW step 16 (200 Ok): 
ensure that { 
when { 

IMS_B receives a SUBSCRIBE from UE_B via IMS_A 
containing an Event header indicating the reg event package} 

then { 

IMS_B sends a 2XX_response to UE_B 
containing an Expires_header 

indicating "the same or lower expiry time than 
specified in the initial SUBSCRIBE" } 

} 



Step 


Direction 


Message 


Comment 








U 

s 
e 
r 
B 


U 
E 
B 


1 

M 

S 
A 


1 

M 

S 
B 






1 








» 










User B registers in IMS B 


2 








> 

i 


> 




REGISTER 


UE_B sends a REGISTER to IMS_A 


3 




REGISTER 


IMS_A forwards the REGISTER to IMS_B 


4 


< 


401 Unauthorized 


IMS B responds with 401 Unauthorized to 
IMS_A 


5 


401 Unauthorized 


IMS_A forwards the 401 Unauthorized to UE_B 


6 


> 


REGISTER 


UE_B sends the same REGISTER containing 
authentication challenge response to IMS A 


7 








» 




REGISTER 


IMS_A forwards the REGISTER to IMS B 


8 


< 

» 


200 OK 


IMS B responds with 200 OK 


9 


i 

> 

i 


200 OK 


IMS_A forwards the 200 OK response to UEB 


10 


SUBSCRIBE 


IMS_A sends a SUBSCRIBE to IMS_B 


11 


« 

« 

» 


200 OK 

or 202 Accepted 


IMS_B responds with a 200 OK or 202 
Accepted 


12 


NOTIFY 


IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 


13 


200 OK 


IMS_A responds to the NOTIFY with a 200 OK 


14 


» 

< 


SUBSCRIBE 


UE_B sends a SUBSCRIBE (reg event 
package) to IMS A 


15 


SUBSCRIBE 


IMS A forwards the SUBSCRIBE request to 
IMS B 


16 


200 OK or 

202 Accepted 


IMS_B responds with 200 OK or 202 Accepted 


17 


200 OK or 
202 Accepted 


IMS_A forwards the 200 OK response to UE B 
or 202 Accepted 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 
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E 


M 


M 
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B 


S 


S 


r 




A 


B 


B 









19 
20 
21 
~22~ 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



NOTIFY 



IMS A forwards the NOTIFY to UE B 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 



User B is informed about successful registration 



4.5.2.2 No response from first entry point on REGISTER without topology hiding 



Interoperability Test Description 


Identifier: 


TD IMS 0003 


Summary: 


IMS network chooses a second entry point to the home network of a user that 
requested registration, if the first entry point does not answer, without topology hiding. 


Configuration: 


CF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5203 01 


ES 283 003 [1], clause 5.2.2 |26 


Use Case ref.: 


UC 01 R 




Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• IMS_A configured with multiple entry points for IMS_B 

• IMS_A not configured for topology hiding 

• First entry point determined by the IMS A pointing to a non-existing component 
in IMS B 



Test Sequence: 


Step 






1 


User B registers in IMS B using any user identity 




2 


Verify that UE B shows successful registration 








Conformance 


Check 




Criteria: 


1 


TP_IMS_5203_01 in CFW step 4 (REGISTER): [l-CSCF] 
ensure that { 

when { IMS A receives no response from IMS B } 

then { IMS A sends the REGISTER to another entry point of IMS B } 

} 




2 


TP_IMS_5092_01 in CFW step 9 (200 Ok): 
ensure that { 

when { UE B sends a protected REGISTER to IMS B and 
IMS_A sends the REGISTER to IMS_B 
containing an Authorization_header 

containing an integrity-protected_parameter indicating yes } 
then { IMS_B sends 200_response to IMS_A 

containing the same Path_header as in the protected REGISTER 

and 

containing a P-Associated-URI_header 
containing all registered_public_identities and "its 
associated set of implicitly registered public user identities" 

indicating (first the default_public_user_identity and 

no barred_public_user_identities) and 
containing a Service-Route_header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a Contact_header 

indicating "all contact addresses" 
for the default public user identity of UE B} 

} 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


s 


E 


M 


M 


e 


B 


S 


S 


r 




A 


B 


B 









User B activates the UE in the home network 



10 
11 

l2~ 



13 



14 

T5~ 



16 



17 



19 



20 
21 

~22~ 
"23" 



REGISTER 



UE B sends a REGISTER to IMS A 



REGISTER 



IMS_A forwards the REGISTER to first entry 
point defined for IMS_ B 



REGISTER 



No response from IMS_B 

IMS A sends a REGISTER to another entry 
point defined for IMS B 



401 Unauthorized 



IMS_B responds with 401 Unauthorized to 
IMS A 



401 Unauthorized 



IMS A forwards the 401 Unauthorized to UE B 



REGISTER 



UE_B sends the same REGISTER containing 
authentication challenge response to IMS_A 



REGISTER 



IMS A forwards the REGISTER to IMS B 



200 OK 



IMS_B responds with 200 OK 



200 OK 



IMS_A forwards the 200 OK response to UE_B 



SUBSCRIBE 



IMS A sends a SUBSCRIBE to IMS B 



200 OK or 202 
Accepted 



IMS_B responds with a 200 OK or 202 
Accepted 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



200 OK 



IMS_A responds to the NOTIFY with a 200 OK 



SUBSCRIBE 



SUBSCRIBE 



UE_B sends a SUBSCRIBE (reg event 
package) to IMS_ A 



IMS_A forwards the SUBSCRIBE request to 
IMS B 



200 OK or 
202 Accepted 



IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 



200 OK or 
202 Accepted 



IMS_A forwards the 200 OK or 202 Accepted 
response to UE B 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



NOTIFY 



IMS A forwards the NOTIFY to UE B 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 



User B is informed about successful registration 



4.5.2.3 No response from first entry point on REGISTER with topology hiding 



Interoperability Test Description 


Identifier: 


TD IMS 0003H 


Summary: 


IMS network chooses a second entry point to the home network of a user that 
requested registration, if the first entry point does not answer. With topology hiding 


Configuration: 


CF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5402 01 


ES 283 003 [1], clause 5.10.2.1 fl 


Use Case ref.: 


UC 01 R 




Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• IMS_A configured with multiple entry points for IMS_B 

• IMS_A configured for topology hiding 

• First entry point determined by the IMS A pointing to a non-existing component 
in IMS B 
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Interoperability Test Description 



Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows successful registration 






Conformance 
Criteria: 


Check 




1 


TP_IMS_5402_01 in CFW step 4 (REGISTER): [IBCF] 
ensure that { 
when { UE_B sends a REGISTER to IMS_A and 
IMS B does not send a response to IMS A } 
then { IMS_A sends the original REGISTER to 

another entry point of IMS B } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


s 


E 


M 


M 


e 


B 


S 


S 


r 




A 


B 


B 









User B activates the UE in the home network 



10 
11 

l2~ 



13 



14 

T5~ 



16 



REGISTER 



UE B sends a REGISTER to IMS A 



REGISTER 



IMS_A forwards the REGISTER to first entry 
point defined for IMS_ B 



REGISTER 



No response from IMS_B 



401 Unauthorized 



IMS A sends a REGISTER to another entry 
point defined for IMS B 



IMS_B responds with 401 Unauthorized to 
IMS A 



401 Unauthorized 



IMS A forwards the 401 Unauthorized to UE B 



REGISTER 



UE_B sends the same REGISTER containing 
authentication challenge response to IMS_A 



REGISTER 



IMS A forwards the REGISTER to IMS B 



200 OK 



IMS_B responds with 200 OK 



200 OK 



IMS_A forwards the 200 OK response to UE_B 



SUBSCRIBE 



IMS A sends a SUBSCRIBE to IMS B 



200 OK or 
202 Accepted 



IMS_B responds with a 200 OK or 202 
Accepted 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



200 OK 



IMS_A responds to the NOTIFY with a 200 OK 



SUBSCRIBE 



UE_B sends a SUBSCRIBE (reg event 
package) to IMS_A 



SUBSCRIBE 



IMS_A forwards the SUBSCRIBE request to 
IMS B 



17 



19 



20 
21 

~22~ 
"23" 



200 OK or 
202 Accepted 



IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 



200 OK or 
202 Accepted 



IMS_A forwards the 200 OK or 202 Accepted 
response to UE_B 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



NOTIFY 



IMS A forwards the NOTIFY to UE B 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 



User B is informed about successful registration 
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4.5.2.4 403 response to REGISTER from an un-trusted domain without topology 
hiding 



Interoperability Test Description 


Identifier: 


TD IMS 0004 


Summary: 


IMS network sends 403 response when attempting registration from a different trust 
domain without topology hiding 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5129 01 


ES 283 003 [1], clause 5.3.1.2 V 


Use Case ref.: 


UC 01 R 



Pre-test 
conditions: 



HSS of IMS_B is configured according to table 1 

UE_B IP bearers established to IMS_A as per clause 4.2.1 

IMS_B not configured for topology hiding 

IMS A and IMS B are in different trust domains 



Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows unsuccessful registration 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5129_01 in CFW step 3 (REGISTER) [l-CSCF]: 
ensure that { 

when { UE B sends a valid initial REGISTER to IMS B 

and IMS_B receives the REGISTER } 
then { IMS B sends a 403 response to IMS A } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


s 


E 


M 


M 


e 


B 


S 


S 


r 




A 


B 


B 









User B activates the UE in a visited network 



REGISTER 



UE B sends a REGISTER to IMS A 



REGISTER 



IMS A forwards the REGISTER to IMS B 



403 Forbidden 



IMS B responds with 403 Forbidden to 
IMS A 



403 Forbidden 



IMS A forwards the 403 Forbidden to UE B 



User B is informed about the registration is 
rejected 



4.5.2.5 



403 response to REGISTER from an un-trusted domain with topology hiding 



Interoperability Test Description 


Identifier: 


TD IMS 0004H 


Summary: 


IMS network sends 403 response when attempting registration from a different trust 
domain with topology hiding 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5411 01 


ES 283 003 [1], clause 5.10.3.1 1f1 


Use Case ref.: 


UC 01 R 



Pre-test 
conditions: 



HSS of IMS_B is configured according to table 1 

UE_B IP bearers established to IMS_A as per clause 4.2.1 

IMS_B configured for topology hiding 

IMS A and IMS B are in different trust domains 
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Interoperability Test Description 



Test Sequence: 


Step 




1 


User B registers in IMS B using any user identity 


2 


Verify that UE B shows unsuccessful registration 




Conformance 
Criteria: 


Check 




1 


TP_IMS_541 1_01 in CFW step 3 (REGISTER) [IBCF]: 
ensure that { 

when { UE B sends a valid REGISTER to IMS B and 

IMS_B sends the REGISTER to IMS_A } 
then { IMS B sends a 403 response to IMS A } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


s 


E 


M 


M 


e 


B 


S 


S 


r 




A 


B 


B 









User B activates the UE in a visited network 



REGISTER 



UE B sends a REGISTER to IMS A 



REGISTER 



IMS A forwards the REGISTER to IMS B 



403 Forbidden 



IMS B responds with 403 Forbidden to 
IMS A 



403 Forbidden 



IMS A forwards the 403 Forbidden to UE B 



User B is informed about the registration is 
rejected 



4.5.2.6 



Network initiated re-registration with new contact information. 



Interoperability Test Description 


Identifier: 


TD IMS 0005 


Summary: 


IMS network supports network initiated re-registration upon receipt of a new 
registration with new contact information 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5088 01 


ES 283 003 [1], clause 5.4.1.2.1 V 


Use Case ref.: 


UC 01 R 



Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B has been registered using any user identity in IMS_B via IMS_A but has 
then physically unplugged, i.e. without de-registration 

• UE_B is configured to use AKA authentication 








Test Sequence: 


Step 






1 


UE_B is physically connected to IMS_B 




2 


Verify that UE_B shows successful registration 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5088_01 in CFW step 2 (REGISTER) and 6 (NOTIFY): 
ensure that { 
when { UE_B sends an initial REGISTER to IMS_B 
containing an Authorization_header 

not containing an integrity-protected_parameter or 
containing an integrity-protected parameter indicating no } 
then { IMS_B sends a NOTIFY to IMS_A 
containing a Request URI 

indicating the P-CSCF_SIP_URI of IMS_A and 
containing an Event_header 

containing the reg_event_package and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 
containing for each registered_public_identity of UEB 
a registrationjelement 
(containing an aor_attribute 

indicating registered_public_identity of UE B and 
containing a state_attribute 

inriimfinn ff*rminzif£*ri anri 
it iLiiuctiii iy ici 1 1 in iciiCLi at iu 

containing a contact_subelement 
(containing an event_attribute 

indicating deactivated or rejected 
containing a state_attribute indicating terminated and 
containing a URI_subelement 

indicating the contact address of UE B) 

)} 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


s 


E 


M 


M 


e 


B 


S 


S 


r 




A 


B 


B 









User B connects UE_B to IMS_B 



29 

30 

~3T 
32 
33 



REGISTER 



UE B sends a REGISTER to IMS B 



401 Unauthorized 



IMS_B responds with 401 Unauthorized to 
UE B 



REGISTER 



UE B sends a REGISTER to IMS B 



200 OK 



IMS_B responds with 200 OK to UE_B 



NOTIFY 



IMS B sends a NOTIFY to IMS A 



34 
35 



200 OK 



IMS_A responds with a 200 OK IMS_B 



User B is informed about the successful re- 
registration 



4.5.2.7 Network initiated deregistration by the S-CSCF 



Interoperability Test Description 


Identifier: 


TD IMS 0006 


Summary: 


IMS network can initiate user de-registration, e.g., when a user runs out of credit 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5093 01 


ES 283 003 [1 ], clause 5.4.1 .5 %6 


Use Case ref.: 


UC 01 R 




Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B registered in IMS_B via IMS_A using any user identity 

• IMS A within the trust domain of IMS B 
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Interoperability Test Description 



Test Sequence: 


Step 




1 


IMS B is triggered manually to de-register user B 


2 


Verify that UE B shows successful de-registration 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5093_01 in CFW step 23 and 27 
ensure that { 

when { IMS B receives an network originated deregistration event } 
then { 

IMS_B sends a NOTIFY to IMS_A 
containing a Request_URI 

indicating UEB and 
containing an Eventjneader 

indicating the reg_event_package and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 
containing for each registered_public_identity of UE B 
a registration_element 
(containing an aor_attribute 

indicating registered_public_identity of UE B and 
containing a state_attribute 
indicating terminated and 
containing a contact_subelement 
(containing an event_attribute 

indicating deactivated or rejected 
containing a state_attribute indicating terminated and 
containing an URI_subelement 
indicating the contact address of UE B) and 
IMS_B sends a NOTIFY to IMS_A 
containing a Request URI 

indicating P-CSCF_SIP_URI of IMS_A and 
containing an Eventjneader 

indicating the reg_event_package and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 

containing for each registered_public_identity of UE B 
a registration_element 
(containing an aor_attribute 

indicating registered_public_identity of UE B and 
containing a state_attribute 
indicating terminated and 
containing a contact_subelement 
(containing an event_attribute 

indicating deactivated or rejected and 
containing a state_attribute indicating terminated and 
containing an URI_subelement 
indicating the contact address of UE B) } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


s 


E 


M 


M 


e 


B 


S 


S 


r 




A 


B 


B 









IMS_B is triggered to de-register user B 



IMS_B sends a NOTIFY to IMS_A, containing 
UE B's de-registration 



23 



24 



25 
26 



NOTIFY 



NOTIFY 



IMS_B sends a NOTIFY to UE_B, containing 
UE_B's de-registration 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


s 


E 


M 


M 


e 


B 


S 


S 


r 




A 


B 


B 









27 



28 
29 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
IMS_A's de-registration 



200 OK 



IMS_A responds to the NOTIFY with a 200 OK 



User B is informed about de-registration 



4.5.2.8 



Network initiated re-authentication by the S-CSCF 



Interoperability Test Description 


Identifier: 


TD IMS 0007 


Summary: 


IMS network can initiate user re-authentication 


Configuration: 


CF ROAM REG 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5094 01 


ES 283 003 [1 ], clause 5.4.1 .6 %2 


Use Case ref.: 


UC 01 R 


Pre-test 
conditions: 


• HSS of IMS_B is configured according to table 1 

• UE_B IP bearers established to IMS_A as per clause 4.2.1 

• UE_B registered in IMS_B using any user identity 

• IMS_A within the trust domain of IMS_B 

• Event received in S-CSCF of IMS B to re-authenticate UE B 











Test Sequence: 


Step 






1 


IMS_B network is triggered to re-authenticate user B 




2 


Verify that UE_B shows successful registration 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5094_01 in CFW steps 23 and 27 
ensure that { 

when { IMSB receives an network_originated_reauthentication_event } 
then { 

IMS_B sends a NOTIFY to UE_B 
containing a Request_URI 

indicating UEB and 
containing an Event_header 

indicating the reg_event_package and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 

containing for each registered_public_identity of UE B 
a registration_element 
(containing an aor_attribute 

indicating a registered_public_identity of UE B and 
containing a state_attribute 

indicating active and 
containing a contact_subelement 
(containing an event_attribute 

indicating shortened and 
containing a state_attribute indicating active and 
containing an URI_subelement 

indicating the contact_address of UE B and 
containing an expiry attribute) and 
IMS_B sends a NOTIFY to IMS_A - P-CSCF 
containing a Request URI 

indicating the P-CSCF_SIP_URI of IMS_A and 
containing an Event_header 

indicating the reg_event_package and 
containing a Route_header 

indicating the original Route_header from SUBSCRIBE and 
containing a Message_Body 

containing for each registered_public_identity of UE B 
a registration_element 
(containing an aor_attribute 

indicating a registered_public_identity of UE B and 
containing a state_attribute 

inriirzitinn arfix/P and 
it iLiiL/CiLii iy aLrlivc at IL* 

containing a contact_subelement 
(containing an event_attribute 

indicating shortened and 
containing a state_attribute indicating active and 
containing an URI_subelement 

indicating the contact_address of UE B and 
containing an expiry attribute) } 

} 
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Step 



Direction 



Message 



Comment 
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U 
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I 
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B 


B 









IMS_B is triggered to re-authenticate user B 



23 



24 



25 
26 
27 

28 
29 

30 
231 
32 
33 
34 



35 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE B's re-authentication 



NOTIFY 



IMS_B sends a NOTIFY to UE_B, containing 
UE re-authentication 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 



NOTIFY 



200 OK 



REGISTER 



IMS_B sends a NOTIFY to IMS_A, containing 
IMS A's re-authentication 

IMS_A responds to the NOTIFY with a 200 OK 



REGISTER 



UE_B sends REGISTER containing 
authentication challenge response to IMS_A 



IMS A forwards the REGISTER to IMS B 



200 OK 



IMS_B responds with 200 OK 



200 OK 



IMS_A forwards the 200 OK response to UE_B 



SUBSCRIBE 



IMS A sends a SUBSCRIBE to IMS B 



200 OK or 
202 Accepted 



IMS_B responds with a 200 OK or 202 
Accepted 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



36 
37 

~38~ 
39 



40 



41 



42 
~43~ 

44 
~45~ 



200 OK 



IMS_A responds to the NOTIFY with a 200 OK 



SUBSCRIBE 



SUBSCRIBE 



UE_B sends a SUBSCRIBE (reg event 
package) to IMS_ A 



IMS A forwards the SUBSCRIBE to IMS B 



200 OK or 
202 Accepted 



IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 



200 OK or 
202 Accepted 



IMS_A forwards the 200 OK or 202 Accepted 
response to UE B 



NOTIFY 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



NOTIFY 



IMS A forwards the NOTIFY to UE B 



200 OK 



UE_B responds to the NOTIFY with a 200 OK 



200 OK 



IMS A forwards the 200 OK to IMS B 



User B is informed about successful registration 



4.5.2.9 



First time registration in a visited IMS network with topology hiding 



Interoperability Test Description 


Identifier: 


TD IMS 0008 


Summary: 


First time registration via a visited IMS network with topology hiding 


Configuration: 


CF ROAM REG 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5134 01 


ES 283 003 [1], clause 5.10.4.1 H5 


TP IMS 5405 01 


ES 283 003 [1], clause 5.10.2.2 V 


Use Case ref.: 


UC_01_R 



Pre-test 
conditions: 



HSS of IMS_B is configured according to table 1 

UE_B IP bearers established to IMS_A as per clause 4.2.1 

UE_B is not registered 

IMS_A is configured for topology hiding 



Test Sequence: 



Step 



User B registers in IMS B using any user identity 



Verify that UE_B shows successful registration 
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Interoperability Test Description 



Conformance 
Criteria: 


Check 




1 


TP_IMS_5134_01 in CFW step 3, 7 (REGISTER): 
ensure that { 
when { UE B sends a REGISTER to IMS A } 
then { IMS_A sends the REGISTER to IMS_B 

containing an additional topmost Path header 
indicating the IBCF SIP URI of IMS A } 

} 




3 


TP_IMS_5405_01 in CFW step 10, 15 (SUBSCRIBE): 
ensure that { 
when { UE B sends a SUBSCRIBE to IMS B } 
then { IMS_A sends the SUBSCRIBE to IMS_B 
containing a Via_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 

mntziininn a R&mrri-Rm itc* h&zirifsr 
kjkJi iLdli III ly a nci/U/ U nuuic //c?dlJt?/ 

containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-byjparameter) and 
not containing (a P-Charging-Vector_header and 

a P-Charging-Function-Addresses header) } 

} 



Step 



Direction 



Message 



Comment 



u 
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I 


I 
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A 


B 


B 









User B registers in IMS B 



10 

11 



12 



13 
14 



15 



16 



17 



19 
20 
21 
22 



REGISTER 



UE B sends a REGISTER to IMS A 



REGISTER 



IMS A forwards the REGISTER to IMS B 



401 Unauthorized 



IMS_B responds with 401 Unauthorized to 
IMS A 



401 Unauthorized 



IMS A forwards the 401 Unauthorized to UE B 



REGISTER 



REGISTER 



200 OK 



200 OK 



SUBSCRIBE 



200 OK or 202 
Accepted 



NOTIFY 



200 OK 



SUBSCRIBE 



SUBSCRIBE 



200 OK or 
202 Accepted 



200 OK or 
202 Accepted 



NOTIFY 



NOTIFY 



200 OK 



200 OK 



UE_B sends the same REGISTER containing 
authentication challenge response to IMS_A 



IMS A forwards the REGISTER to IMS B 



IMS_B responds with 200 OK 



IMS_A forwards the 200 OK response to UE_B 



IMS A sends a SUBSCRIBE to IMS B 



IMS_B responds with a 200 OK or 202 
Accepted 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



IMS_A responds to the NOTIFY with a 200 OK 



UE_B sends a SUBSCRIBE (reg event 
package) to IMS_A 



IMS A forwards the SUBSCRIBE request to 
IMS B 



IMS_B responds to the SUBSCRIBE with a 200 
OK or 202 Accepted 



IMS_A forwards the 200 OK or 202 Accepted 
response to UE_B 



IMS_B sends a NOTIFY to IMS_A, containing 
UE_B's registration status 



IMS A forwards the NOTIFY to UE B 



UE_B responds to the NOTIFY with a 200 OK 



IMS A forwards the 200 OK to IMS B 



User B is informed about successful registration 



ETSI 



65 



ETSI TS 186 011-2 V2.2.1 (2009-03) 



4.5.3 Initial Dialog or Subsequent Procedures 



4.5.3.1 



Initial INVITE Dialog Procedures 



4.5.3.1.1 



Initial INVITE Request Procedures - Originating 



4.5.3.1.1.1 



Default SIP URI 



Interoperability Test Description 


Identifier: 


TD IMS 0009 


Summary: 


IMS network can handle establishment of dialogs for users with default SIP URIs and 




resolve Tel URI E.164 numbers 




Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 




TP IMS 5097 01 


ES 283 003 [1], clause 5.4.3.2 V 




TP IMS 5097 02 


ES 283 003 [1], clause 5.4.3.2 V 




TP IMS 5097 04 


ES 283 003 [1], clause 5.4.3.2 V 




TP IMS 5107 02 


ES 283 003 [1], clause 5.4.3.2 H49 




TP IMS 5107 01 


ES 283 003 [1], clause 5.4.3.2 ^49 




TP IMS 5115 01 


ES 283 003 [1], clause 5.4.3.3 H39 




TP IMS 5115 03 


ES 283 003 [1], clause 5.4.3.3 H39 




TP IMS 5115 02 


ES 283 003 [1], clause 5.4.3.3 H39 




TP IMS 5115 04 


ES 283 003 [1], clause 5.4.3.3 H39 




TP IMS 5131 01 


ES 283 003 [1], clause 5.3.2.1 H37 




TP IMS 5131 02 


ES 283 003 [1], clause 5.3.2.1 H37 


Use Case ref.: 


UC 02 I 







Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A is registered in IMS_A as userSIP_priv according to table 1 
UE_B is registered in IMS_B as userSIP_priv according to table 1 
IMS_A within the trust domain of IMS_B 

Common DNS is configured with an ENUM entry for the Tel URI E.164 Number 
of userSIP of IMS B 



Test Sequence: 


Step 






1 


User A calls user B's TelJJRI (i.e. userSIP in IMS_B) 




2 


Verify that user B is informed of incoming call of User A 




3 


Verify that user A is informed that UE B is ringing 




4 


User B answers the call 




5 


Verify that user A is informed that call has been answered 




6 


Verify that user B is informed that the call is established 




7 


User A ends the call 




8 


Verify with UE_B that call has been released 




9 


Verify with UE_A that call has been released 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 

when { UE_A sends an initial INVITE to UE_B } 
then { IMS_B receives the initial INVITE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 

[L/UI ILall III ly all IL/IU fJctl ctl 1 l&lcl at IU 

containing a orig-ioi_parameter indicating IMS_A and 

not containing a term-ioi_parameter) and 
containing a Record-Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo header } 

} 




2 


TP_IMS_5097_02 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

not containing a P-Preferred-ldentity_header or 

r*r\ntziinina o P-Pr&farrari-lri&ntitw HacxH&r' 
L>ui Hail in ly a 1 i i tut;! i luci iliiy I i&au&i 

not indicating a Tel URI of UE A} 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE A 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel URI of UE A} 

} 




3 


TP_IMS_5097_04 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 
containing a Request_URI 
indicating a Tel URI} 
then { IMS_A sends a DNS_Query to DNS 

containing the Tel_URI_E. 164_Number } 

\A/h&n I IhAQ A ranai\/ac /~)A/Q Rocnnnco fmm /~)A/Q 

Vvl ItSI 1 J //WO r\ /t?Ot;/Vt?0 L/lVu liK^OfJUl /oc; IIUIII L//VO 

containing a NAPTR Resource Record 

indicating the SIP URI of UE Bj 
then { IMS_A sends the initial INVITE to IMS_B 
containing a Request URI 

indicating the SIP_URI of UE_B 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter } 

} 




4 


TP_IMS_5107_02 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { IMS_B receives the ACK 

not containing Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing a P-Access-Network-lnfo header } 

j 




5 


TP_IMS_5107_01 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

containing no Route_header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing a P-Access-Network-lnfo header } 

} 
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Interoperability Test Description 




6 


TP_IMS_5115_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a 180_response to UEA } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operator ^identifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 

} 




7 


TP_IMS_5115_03 in CFW step 10 (180 Ringing): 
ensure that { 
when { UE B sends a 1xx_response to UE A 

(not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity header 
indicating a SIP_URI of UE_B) } 
then { IMS_A receives the 1xx_response from IMS_B 
containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity header 
indicating a Tel URI of UE Bl } 

} 




8 


TP_IMS_51 15_02 in CFW step 15 (2xx): 
ensure that { 
when { UE B sends a 2xx_response to UE A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 

} 




9 


TP_IMS_51 15_04 in CFW step 15 (2xx): 
ensure that { 
when { UE B sends a 2xx_response to UE A 

(not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel_URI of UE_B) } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE B and 
containing a P-Asserted-ldentity_header 
indicating a Tel URI of UE B} 

} 




10 


TP_IMS_5131_01 in CFW step 10 (180 Ringing): 
ensure that { 

when { UE B sends a 180_response to UE A } 

then { IMS_B sends the 180_response to IMS_A 

not containing a P-Charging-Function-Addresses header } 

} 




11 


TP_IMS_5131_02 in CFW step 15 (2xx) 
ensure that { 
when { UE B sends a 2xx_response to UE A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 

} 

} 
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Step 



Direction 



Message 



Comment 
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B 




r 


A 












B 



4a 



4b 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UEA supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



DNS QUERY 



IMS_A sends DNS QUERY to common DNS 
containing E.164 TEL URI 



DNS 

RESPONSE 



INVITE 



Common DNS sends DNS RESPONSE 
containing NAPTR resource record to IMS_A 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



User B is informed of incoming call of User A 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



10 



11 



12 
~13~ 
14 

l5~ 
16 
17 



19 

20 

21 
22A 
23A 
24A 
25A 
26A 
27A 
28A 
29A 



180 Ringing 



IMSB forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 180 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



200 OK 



User B answers call 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



200 OK 



IMS B forwards 200 OK response to IMS A 



200 OK 



IMS_A forwards the 200 OK response to UE A 



User A is informed that call has been answered 



ACK 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



User B is informed that the call is established 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE A 
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3.1.1.2 Default SIP URI 



Interoperability Test Description 


Identifier: 


TD IMS 0009F 


Summary: 


IMS network can handle establishment of a call when the call is being offered to 
multiple terminals 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 01 


ES 283 003 [1], clause 5.4.3.2 |1 


TP IMS 5097 02 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5097 04 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5107 02 


ES 283 003 [1], clause 5.4.3.2 H49 


TP IMS 5107 01 


ES 283 003 [1], clause 5.4.3.2 H49 


TP IMS 5115 01 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5115 03 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5115 02 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5115 04 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5131 01 


ES 283 003 [1], clause 5.3.2.1 H37 


TP IMS 5131 02 


ES 283 003 [1], clause 5.3.2.1 H37 


Use Case ref.: 


UC 12 I 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A as userSIP_priv according to table 1 

• UE B is registered in IMS BviaUE B1 and UE B2 as userSIP according to 
table 1 

• IMS A within the trust domain of IMS B 


Test Sequence: 


Step 




1 


User A calls User B 


2 


User B is informed of incoming call of User A on UE B1 


3 


User B is informed of incoming call of User A on UE B2 


4 


User A is informed that a UE of User B is ringing 


5 


User B answers call on UE B2 


6 


User B is informed at UE_B1 that the call is no longer offered 


7 


User A is informed that call has been answered 


8 


User B is informed that the call is established 


9 


User A ends the call 


10 


Verify with UE_B that call has been released 


11 


Verify with UE A that call has been released 



Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 

when { UE A sends an initial INVITE to UE B} 
then { IMS_B receives the initial INVITE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 

(containing an icid_parameter and 

containing a orig-ioijparameter indicating IMS_A and 

not containing a term-ioi_parameter) and 
containing a Record- Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo header } 

} 



ETSI 



70 



ETSI TS 186 011-2 V2.2.1 (2009-03) 



Interoperability Test Description 




3 


TP_IMS_5107_02 in CFW step 28 (ACK): 
ensure that { 
when { UE_A sends ACK to UEJ3 } 
then { IMS_B receives the ACK 

not containing Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing a P-Access-Network-lnfo header } 

} 




4 


TP_IMS_5107_01 in CFW step 33A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

containing no Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing a P-Access-Network-lnfo header } 

} 




5 


TP_IMS_5115_01 in CFW step 10 and 17 (180 Ringing): 
ensure that { 
when { UEB sends a 180_response to UEA } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 

} 




6 


TP_IMS_51 1 5_02 in CFW step 24 (2xx): 
ensure that { 
when { UE B sends a 2xx_response to UE A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioijparameter 
indicating operator identifier of IMS B 

} 




7 


TP_IMS_5131_01 in CFW step 10 and 17 (180 Ringing): 
ensure that { 

when { UE B sends a 180_response to UE A } 

then { IMS_B sends the 180_response to IMS_A 

not containing a P-Charging-Function-Addresses header } 

} 




8 


TP_IMS_5131_02 in CFW step 25 (2xx) 
ensure that { 
when { UE B sends a 2xx_response to UE A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 

} 

} 
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Step 



Direction 



Message 



Comment 
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U 
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e 


r 




A 


B 




r 


A 










B 



10 



11 



12 
T3~ 
14 



15 



16 



17 



19 
20 

~2T 
~22~ 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



INVITE 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards INVITE to UE B1 



100 Trying 



180 Ringing 



UE_B1 optionally responds with a 100 Trying 
provisional response 



User B is informed on UE B1 of incoming call of 



cor 



180 Ringing 



180 Ringing 



INVITE 



100 Trying 



180 Ringing 



180 Ringing 



180 Ringing 



200 OK 



CANCEL 



200 OK 



UE_B1 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



IMS_B forwards 180 Ringing response to 
IMS A 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that a UE of User B is ringing 



IMS B forwards INVITE to UE B2 



UE_B2 optionally responds with a 100 Trying 
provisional response 



User B is informed on UE_B2 of incoming call of 
User A 



UE_B2 responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



IMSB forwards 2 nd 180 Ringing response to 
IMS A 



IMS_A forwards the 2 nd 180 Ringing response 
to UE A 



User B answers call at UE_B2 



UE_B2 responds to INVITE with 200 OK to 
indicate that the call has been answered 



IMS_B sends CANCEL request to UE_B1 



UE_B1 sends 200 OK response to the CANCEL 
request to IMS_B 



23 



24 

~25~ 
26 
27 

28 

29 
30 



UE_B1 informs user B that the call is no longer 
offered to this UE and stops ringing 



200 OK 



IMS B forwards 200 OK response to IMS_A 



200 OK 



ACK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



User B is informed that the call is established 



31A 
32A 
33A 
34A 
35A 
36A 
37A 
38A 
39A 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS B forwards 200 OK response to IMS A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has ended 



ETSI 



72 



ETSI TS 186 011-2 V2.2.1 (2009-03) 



4.5.3.1.1.3 Default Tel URI 



Interoperability Test Description 


Identifier: 


TD IMS 0010 


Summary: 


IMS network can handle establishment of dialogs for users with default TEL URIs 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 01 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5097 03 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5107 02 


ES 283 003 [1], clause 5.4.3.2 H49 


TP IMS 5107 01 


ES 283 003 [1], clause 5.4.3.2 ^49 


TP IMS 5115 01 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5115 05 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5115 02 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5115 06 


ES 283 003 [1], clause 5.4.3.3 H39 


TP IMS 5131 01 


ES 283 003 [1], clause 5.4.3.3 H37 


TP IMS 5131 02 


ES 283 003 [1], clause 5.3.2.1 %37 


Use Case ref.: 


UC 02 I 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using userTEL_priv according to table 1 

• UE_B is registered in IMS_B using userTEL_priv according to table 1 

• IMS A within the trust domain of IMS B 


Test Sequence: 


Step 




1 


User A calls user B (i.e. userTEL in IMS_B) 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE_B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE_B that call has been released 




9 


Verify with UE_A that call has been released 




Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_01 in CFW step 4 (INVITE): 
ensure that { 

when { UE A sends an initial INVITE to UE B} 
then { IMS_B receives the initial INVITE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector_header 

(containing an icidjparameter and 

containing a orig-ioi_parameter indicating IMS_A and 

not containing a term-ioijparameter) and 
containing a Record- Route_header 

indicating the originating S-CSCF_SIP_URI and 
containing a P-Charging-Vector header 

not containing a access-network-charging-info_parameter and 
not containing a P-Access-Network-lnfo header } 

} 
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Interoperability Test Description 




2 


TP_IMS_5097_03 in CFW step 4 (INVITE) 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI of UE_A } 
then { IMS_B receives the initial INVITE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UEA 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI of UE A} 

} 




3 


TP_IMS_5107_02 in CFW step 19 (ACK): 
ensure that { 
when { UE_A sends ACK to UE_B } 
then { IMS_B receives the ACK 

not containing Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing a P-Access-Network-lnfo header } 

} 




4 


TP_IMS_5107_01 in CFW step 24A (BYE): 
ensure that { 
when { UE_A sends BYE to UE_B } 
then { IMS_B receives the BYE 

containing no Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing a P-Access-Network-lnfo header } 

} 




5 


TP_IMS_5115_01 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a 180_response to UE A } 
then { IMS_A receives the 180_response from IMS_B 
containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator Jdentifier of IMS_B 




6 


TP_IMS_5115_05 in CFW step 10 (180 Ringing): 
ensure that { 
when { UE B sends a 1xx_response to UE A 

(not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI) } 
then { IMS_A receives the Ixxresponse 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI } 

} 




7 


TP_IMS_51 15_02 in CFW step 15 (2xx): 
ensure that { 
when { UE B sends a 2xx_response to UE A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioijparameter 
indicating operator identifier of IMS B 

} 
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Interoperability Test Description 




8 


TP_IMS_51 15_06 in CFW step 15 (2xx): 
ensure that { 
when { UEB sends a 2xx_response to UEA 

(not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI) } 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI } 

} 




9 


TP_IMS_5131_01 in CFW step 10 (180 Ringing): 
ensure that { 

when { UE B sends a 180_response to UE A } 

then { IMS_B sends the 180_response to IMS_A 

not containing a P-Charging-Function-Addresses header } 

} 




10 


TP_IMS_5131_01 in CFW step 15 (2xx) 
ensure that { 
when { UE B sends a 2xx_response to UE A } 
then { IMS_A receives the 2xx_response from IMS_B 
containing a P-Charging-Vector_header 
containing an orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B 

} 

} 



Step 



Direction 



Message 



Comment 
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r 


A 










B 



User A calls User B 



INVITE 



100 Trying 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



10 



11 



12 
T3~ 
14 

l5~ 
16 
17 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



180 Ringing 



180 Ringing 



180 Ringing 



200 OK 



200 OK 



200 OK 



ACK 



UE_B optionally responds with a 100 Trying 
provisional response 

UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



IMSB forwards 180 Ringing response to 
IMS A 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



IMS B forwards 200 OK response to IMS A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 



UE_A acknowledges the receipt of 200 OK for 
INVITE 
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Step 



Direction 



Message 



Comment 
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19 

20 

21 
22A 
23A 
24A 
25A 
26A 
27A 
28A 
29A 
30A 



ACK 



ACK 



BYE 



BYE 



BYE 



200 OK 



200 OK 



200 OK 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to UE B 



User B is informed that the call is established 



User A ends call 



UE A releases the call with BYE 



IMS A forwards BYE to IMS B 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



UE B sends 200 OK for BYE 



IMS_B forwards 200 OK response to IMS_ 



IMS_A forwards the 200 OK response to UE_A 



User B is informed that call has ended 



4.5.3.1.1.4 



Rejection of call from barred user 



Interoperability Test Description 


Identifier: 


TD IMS 0011 


Summary: 


IMS network does not establish call to barred user 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5108 05 


ES 283 003 [1], clause 5.4.3.3 1f1 


Use Case ref.: 


UC 02 I 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS_A within the trust domain of IMS_B 

• User B has two public identities in IMS B out of which one of has been barred 



Test Sequence: 


Step 






1 


User A calls user B using barred user identity 




2 


Verify that user A is informed that call cannot be established 








Conformance 


Check 




Criteria: 


1 


TP_IMS_5108_05 in CFW step 6 (404 response): 
ensure that { 
when {UE A sends an initial INVITE to UE B and 
IMS_A sends the INVITE to IMS_B 
containing a Request_URI 

indicating a barred_user in IMS_B } 
then { IMS B sends 404 response to IMS A } 

I 
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Step 



Direction 
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Comment 
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10 



INVITE 



100 Trying 



INVITE 



100 Trying 



404 Not 
Found 



404 Not 
Found 



ACK 



ACK 



User A calls User B 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS_B responds to the INVITE with 404 Not 
Found 



IMS_A forwards the 404 Not Found response to 
UE A 



User A is informed that call has failed 



UE A acknowledges the response 



IMS A forwards the ACK to IMS B 



4.5.3.1 .1 .5 Rejection of call to non-existing user 



Interoperability Test Description 


Identifier: 


TD IMS 0012 


Summary: 


IMS network rejects call to non existing user 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 




TP IMS 5132 01 


ES 283 003 [1], clause 5.3.2.1 H28 


Use Case ref.: 


UC_01_I 








Pre-test 


• HSS of IMS_A and is configured according to table 1 


conditions: 


• UE_A have IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• IMS A within the trust domain of IMS B 



Test Sequence: 


Step 




1 


User A calls user B indicating a non existing identity within IMS B domain 




2 


Verify that user A is informed that call cannot be established 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5132_01 in CFW step 6 (404 Not Found): 
ensure that { 
when { UEA sends an initial INVITE 
containing a Request_URI 
indicating a non existing user in IMS B and 
IMS_A sends the INVITE to IMS_B } 
then { IMS B sends an appropriate (e.g. 404 or 604) to IMS A } 

} 
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Step 



Direction 



Message 



Comment 
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10 



INVITE 



100 Trying 



INVITE 



100 Trying 



404 Not 
Found 



404 Not 
Found 



ACK 



ACK 



User A calls User B 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs 
that UE A supports 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B responds with 404 Not Found to 
IMS A 



IMS_A forwards the 404 Not Found response to 
UE A 



User A is informed that called user does not 
exist 



UE_A acknowledges the receipt of a 404 final 
response 



IMS A forwards the ACK to IMS B 



4.5.3.1 .1 .6 Rejection of call to unavailable user 



Interoperability Test Description 


Identifier: 


TD IMS 0013 


Summary: 


IMS network does not establish a call for unavailable user 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5133 01 


ES 283 003 [1], clause 5.3.2.1 H29 


Use Case ref.: 


UC 01 I 


Pre-test 
conditions: 


• HSS of IMS_A and IMS_B is configured according to table 1 

• UE_A has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is not registered in IMS_B 



Test Sequence: 


Step 






1 


User A calls a valid user B identity 




2 


Verify that user A is informed that user B is not reachable or equivalent 








Conformance 


Check 




Criteria: 


1 


TP_IMS_5133_01 in CFW step 6 (4xx): 

ensure that { 
when { UE_A sends INVITE to UE_B } 
then { IMS B sends a 4xx response to IMS A } 

} 
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Step 



Direction 



Message 



Comment 
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10 



INVITE 



100 Trying 



INVITE 



100 Trying 



4xx 



4xx 



ACK 



ACK 



User A calls User B 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS_B responds with 4xx to IMS_A 



IMS_A forwards the 4xx response to UE_A 



User A is informed that called user is not 
reachable or equivalent 



UE_A acknowledges the receipt of a 4xx final 
response 



IMS A forwards the ACK to IMS B 



4.5.3.1 .1 .7 Initial request to non-registered user with terminating unregistered filter criterion 



Test Description 


Identifier: 


TD IMS 0014 


Summary: 


IMS network can handle initial request to non-registered user with terminating 
unregistered filter criterion 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5109 01 


ES 283 003 [1], clause 5.3.2.1 fl33 


Use Case Ref.: 


UC 01 I 



: 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A has no filter criteria defined in HSS 

• IMS B has terminating unregistered criterion set for UE B on INVITE indicating 
SESSION TERMINATED option and forward the INVITE to AS_B 

• AS_B is unreachable from IMS_B 

• UE_A registered using any user identity 

• UE B not registered as userNOAS_priv according to table 1 






Test Sequence: 


Step 




1 


User A calls user B (i.e. userNOAS in IMS_B) 


2 


Verify that user A is informed that call cannot be established 







Pass Criteria: 


Check 




1 


TP_IMS_5109_01 in CFW step 6 (Error Response): 
ensure that { 

when { UE_A sends INVITE to UE_B } 

then { IMS_B receives the INVITE and 

sends (a 408 response or a 5xx response) to IMS A 

} 

} 
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Step 



Direction 



Message 



Comment 
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User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer indicating 
all desired medias and codecs that UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional response 



408 Request 
Timeout or 
5xx Response 



IMS B responds with 4xx to IMS A 



408 Request 
Timeout or 
5xx Response 



IMS_A forwards the 4xx response to UEA 



User A is informed that called user is not reachable 



4.5.3.1.2 



Dialogue Procedures with Roaming 



4.5.3.1.2.1 



Normal call 



Interoperability Test Description 


Identifier: 


TD IMS 0015 


Summary: 


IMS network handles normal call while UE_B is roaming without topology hiding 
correctly 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 




TP IMS 5046 01 


ES 283 003 [1], clause 5.2.6.3 ^4 




TP IMS 5067 01 


ES 283 003 [1], clause 5.2.7.2 V 




TP IMS 5070 01 


ES 283 003 [1], clause 5.2.7.3 %6 




TP IMS 5301 01 


ES 283 003 [1], clause 5.4.3.3 H56 




TP IMS 5055 01 


ES 283 003 [1], clause 5.2.6.4 fl5 




TP IMS 5055 02 


ES 283 003 [1], clause 5.2.6.4 fl5 




TP IMS 5108 01 


ES 283 003 [1], clause 5.4.3.3 V 


Use Case ref.: 


UC 02 R 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE A and UE B have IP bearers established to IMS_A as per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is registered in IMS_B via IMS_A using any user identity 

IMS_A within the trust domain of IMS_B 

A Service-Route header list exists for UE B in P-CSCF 



Test Sequence: 


Step 






1 


User B calls User A 




2 


Verify that user A is informed of incoming call of User B 




3 


Verify that user B is informed that UE_A is ringing 




4 


User A answers call 




5 


Verify that user B is informed that call has been answered 




6 


Verify that user A is informed that the call is established 




7 


User A ends call 




8 


Verify that user B is informed that call has ended 




9 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5046_01 in CFW step 4 (INVITE) 
ensure that { 

when { IMS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 
containing an additional Via_header 
containing ( the P-CSCF via port number and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF _port_number 

'where it awaits subsequent requests' from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
indicating the "list of Service Route header URIs 
from the registration" and 
not containing P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of UE A and 
containing a P-Charging-Vector_header 
containing an icid parameter } 

} 




2 


TP_IMS_5067_01 in CFW step 4 
ensure that { 

when { IMS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 

containing a P-Charging-Vector_header 
containing a access-network-charging-info parameter 

; 

; 




3 


TP_IMS_5070_01 in CFW step 7 (100 Trying) 
ensure that { 

when { IMSA receives an initial INVITE from UEB } 
then { IMS A sends a 100 response to IMS B 
} 

} 




4 


TP_IMS_5301_01 in CFW step 29A (BYE) 
ensure that { 
when { IMS A receives a BYE from UE A 

} 

then { IMS_A sends the BYE 

containing no Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a topmost Record-Route header 
indicating the S-CSCF SIP URI of IMS A 

} 

} 








5 


TP_IMS_5055_01 in CFW step 12 (180 Ringing) 
ensure that { 

when { IMS A receives a 180_response from UE B } 
then { IMS_A sends a 180_response to IMS_B 
containing a Record-Route header 
containing the P-CSCF_port_number of IMS_A 
"where it expects subsequent requests" and 
not containing a compjparameter and 
not containing a P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 
indicating the address "sent in P-Called_Party-ID header 
sent in the initial request"} 

} 
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Interoperability Test Description 




6 


TP_IMS_5055_02 in CFW step 18 (200 OK) 
ensure that { 

when { IMSA receives a 200_response from UEB } 
then { IMS_A sends the 200_response to IMS_B 
containing a Record-Route_header 
containing the P-CSCF_port_number of IMS_A 
"where it expects subsequent requests" and 
not containing a comp_parameter and 
not containing a P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 
indicating the address "sent in P-Called_Party-ID header 
sent in the initial request" 

} 

} 


7 


TP_IMS_5108_01 in CFW step 6 (INVITE): 
ensure that { 
when {UE A sends an initial INVITE to UE B 
IMS_A sends the INVITE to IMS_B 
containing a P-Charging-Vector_header 
containing an icid parameter } 
then { IMS_B sends the INVITE to IMS_A 
containing no Route header 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
containing the same icid_parameter and 
not containing ioijparameters 
containing a Record-Route header 
containing the S-CSCF SIP URI of IMS B } 

} 



Step 



Direction 



Message 



Comment 
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10 

11 



12 



13 



14 



15 
16 
17 



User B calls User A 



INVITE 



100 Trying 



UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE B supports 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



INVITE 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards the INVITE to IMS A 



100 Trying 



INVITE 



IMSA responds with a 100 Trying 
provisional response 



IMS A forwards the INVITE to UE A 



100 Trying 



UE_A optionally responds with a 100 Trying 
provisional response 



User A is informed of incoming call of User B 



180 Ringing 



180 Ringing 



UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



IMS A forwards 180 Ringing response to 
IMS B 



180 Ringing 



IMS_B forwards the 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 180 Ringing response to 
UE B 



User B is informed that UE_A is ringing 



User A answers call 



200 OK 



UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 
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Step 



Direction 



Message 



Comment 
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18 

19 
20 
21 
22 

23 
24 
25 
26 
27A 
28A 
29A 
30A 
31A 
32A 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



BYE 



BYE 



BYE 



BYE 



IMS A forwards 200 OK response to IMS B 



IMS_B forwards the 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_B 



User B is presented that call in process 



UE_B acknowledges the receipt of 200 OK for 
INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE A 



User A is informed that the call is in progress 



User A ends call 



UE A releases the call with BYE 



IMS A forwards BYE to IMS B 



IMS B forwards BYE to IMS A 



IMS A forwards BYE to UE B 



User B is informed that call has ended 



4.5.3.1 .2.2 Normal call with hold/resume 



Interoperability Test Description 


Identifier: 


TD IMS 0016 


Summary: 


IMS network handles subsequent INVITEs correctly in case of a user initiated call hold 
and resume when home caller puts roaming user on hold and resumes call 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 




TP IMS 5081 01 


ES 283 003 [1], clause 5.2.9.2 V 




TP IMS 5082 01 


ES 283 003 [1], clause 5.2.9.2 %2 




TP IMS 5120 01 


ES 283 003 [1], clause 5.4.3.3 f*8 


Use Case ref.: 


UC 03 R 



: 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5081_01 in CFW step 41 A and 60A (100 Trying): 
ensure that { 

when { UE A sends a subsequent INVITE to UE B and 

IMS_A receives the INVITE from IMS_B } 
then { IMS A sends a 100 response to IMS B } 

} 




2 


TP IIVR <iOS? 01 in HRA/ qtpn 4fiA and fi'iA f?00 OKV 

i i iivio juol u i ill urvv oicu \ di iu \j\jr\ i^uu 

ensure that { 

when { IMSA receives a 200_response from UEB } 
then { IMS_A sends the 200_response to IMS_B 
containing a P-Charging-Vector_header 
containing an updated 

access-network-charging-info _parameter 

} 

} 




3 


TP IM9 <i1?0 0.1 in f.FW <;tpn 40A and RQA HNVITFV 
in iivio j i lu u i hi \j rvv o icu t -T\jr\ &\ i u vjc?/\ 1 1 1 \i v i i i j . 

ensure that { 

when { UE A sends a subsequent INVITE to UE B } 
then { IMS_A receives the INVITE from IMS_B 

not containing a topmost Route header 

containing the S-CSCF_SIP_URI 
containing a Record-Route header 
containing the S-CSCF SIP URI } 

} 





Direction 
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34 
35A 




» 




<; 










User B is presented that call is in progress 
User A puts call on hold 


36A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 






» 


37A 


100 Trying 


IMS_A responds with a 100 Trying provisional 
response 


d 




* 


38A 


INVITE 


IMS_A forwards INVITE to IMS_B 






39A 


100 Trying 


IMS_B responds with a 100 Trying provisional 
response 




40A 


INVITE 


IMS_B forwards INVITE to IMS_A 






41 A 


100 Trying 


IMS A responds with a 100 Trying 
provisional response 




42A 


INVITE 


IMS_A forwards INVITE to UE_B 






43A 
44A 


100 Trying 


UE_B optionally responds with a 100 Trying 

provisional response 

User B is informed that call is on hold 




45A 








< 








200 OK 


UE_B responds to INVITE with 200 OK 
indicating attribute "recvonly" inactive 


> 


46A 


200 OK 


IMS A forwards 200 OK response to IMS B 






47A 


200 OK 


IMS_B forwards 200 OK response to IMS_A 


< — 




48A 


200 OK 


IMS_A forwards the 200 OK response to UE_A 


« 






49A 


ACK 


UE A acknowledges the receipt of 200 OK for 
INVITE 










50A 


ACK 


IMS_A forwards ACK to IMS_B 




— » 


51A 


ACK 


IMS_B forwards ACK to IMS_A 




52A 


ACK 


IMS_A forwards ACK to UE_B 




53A 
54A 




d — 


— » 














User A is informed that call is on hold 
User A resumes call 


55A 
















INVITE 


UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 






» 
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Step 



Direction 



Message 



Comment 
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56A 



57A 
58A 

59A 
60A 

61A 
62A 

63A 
64A 

65A 

66A 
67A 
68A 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



200 OK 



200 OK 



200 OK 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards INVITE to IMS A 



IMSA responds with a 100 Trying 
provisional response 



IMS A forwards INVITE to UE B 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed that call is resumed 



UE_B responds to INVITE with 200 OK 
indicating media attribute "sendrecv" 



IMS A forwards 200 OK response to IMS B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is resumed 



4.5.3.1.2.3 



Subsequent request (other than target refresh) 



Interoperability Test Description 


Identifier: 


TD IMS 0017 


Summary: 


IMS network handles routing information in subsequent requests (other than target 
refresh) received from the UE before forwarding them to another IMS network. 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5052 01 


ES 283 003 [1], clause 5.2.6.3 1156 


Use Case ref.: 


UC 02 R 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_B has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE A registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 






Test Sequence: 


Step 




1 


User B calls User A 


2 


Verify that user A is informed of incoming call of User B 


3 


Verify that user B is informed that UE_A is ringing 


4 


User A answers call 


5 


Verify that user B is informed that call has been answered 


6 


Verify that user A is informed that the call is established 


7 


User B ends call 


8 


Verify that user A is informed that call has ended 


9 


Verify that user B is informed that call has ended 
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Interoperability Test Description 



Conformance 
Criteria: 


Check 




1 


TP_IMS_5052_01 in CFW step 29B (BYE): 

when { IMS_A receives a BYE from UEB } 
then { IMS_A sends the BYE to IMS_B 
not containing a Route header 

indicating the P-CSCF_SIP_URI of IMS_A and 
containing the same Record-Route_header 
as in the previous ACK 

} 

} 



Step 



Direction 



Message 



Comment 
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27B 
28B 
29B 

30B 
31B 
32B 



User B ends call 



BYE 



UEB releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to IMS A 



BYE 



IMS A forwards BYE to UE A 



User A is informed that call has ended 



4.5.3.1 .2.4 Subsequent target refresh request (INVITE) 



Interoperability Test Description 


Identifier: 


TD IMS 0018 


Summary: 


IMS network handles subsequent INVITEs correctly in case of a user initiated call hold 
and resume when roaming caller puts a home user on hold and resumes call 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5048 01 


ES 283 003 [1], clause 5.2.6.3 H26 


TP IMS 5080 01 


ES 283 003 [1], clause 5.2.9.1 V- 


Use Case ref.: 


UC 03 R 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_B configured to perform user initiated hold/resume using INVITE 

• UE_A registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 



Test Sequence: 


Step 






1 


User B calls User A 




2 


Verify that user A is informed of incoming call of User B 




3 


Verify that user B is informed that UE_A is ringing 




4 


User A answers call 




5 


Verify that user B is informed that call has been answered 




6 


Verify that user A is informed that call is established 




7 


User B puts call on hold 




8 


Verify that user A is informed that call is on hold 




9 


Verify that user B is informed that call is on hold 




10 


User B resumes call 




11 


Verify that user A is informed that call is resumed 




12 


Verify that user B is informed that call is resumed 




13 


User A ends call 




14 


Verify that user B is informed that call has ended 




15 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5048_01 in CFW step 38B and 57B (INVITE): 
ensure that { 

when { IMS A receives a subsequent INVITE from UE B} 
then { IMS_A sends the INVITE to IMS_B 

containing an additional topmost Record-Route_header 

mnfaininn ( thp P-(~Z£f~!F nnrt ni imhpr "whprp it Awaits 
subsequent requests" from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional Via_header 
containing ( the P-CSCF via port number and 
(the P-CSCF-FQDN_address or 
the P-CSCF-IP address)) of IMS A } 

} 




2 


TP_IMS_5080_01 in CFW step 38B and 57B (INVITE): 
ensure that { 

when { IMS A receives subsequent INVITE from UE B} 
then { IMS_A sends the INVITE to IMS_B 
containing a P-Charging-Vector_header 

containing an updated access-network-charging-info parameter} 

} 



Step 



Direction 
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35B 
36B 



37B 



38B 

39B 

40B 
41 B 

42B 
43B 

44B 
45B 

46B 
47B 
48B 
49B 

50B 
51 B 
52B 
53B 
54B 
55B 



56B 



57B 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



INVITE 



100 Trying 



INVITE 



User B puts call on hold 



UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards INVITE to IMS A 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to UE A 



UE_A optionally responds with a 100 Trying 
provisional response 



User A is informed that call is on hold 



UE_A responds to INVITE with 200 OK 
indicating attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_B 



UE_B acknowledges the receipt of 200 OK for 
INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS B 



IMS A forwards ACK to UE A 



User B is informed that call is on hold 



User B resumes call 



UE_B sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 
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Step 



Direction 



Message 



Comment 
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58B 



59B 
60B 

61 B 
62B 



63B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to IMS A 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to UE A 



100 Trying 



UE_A optionally responds with a 100 Trying 
provisional response 



User A is informed that call is resumed 



4.5.3.1 .2.5 Subsequent target refresh request (UPDATE), roaming user initiated 



Interoperability Test Description 


Identifier: 


TD IMS 0019 


Summary: 


IMS network handles subsequent UPDATES correctly in case of a user initiated call 
hold and resume when roaming caller puts a home user on hold and resumes call 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 




TP IMS 5080 02 


ES 283 003 [1], clause 5.2.9.1 V- 


Use Case ref.: 


UC 03 R 








Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_B has IP bearers established to their respective IMS networks as per 
clause 4.2.1 

• UE A registered in IMS_A 

• UE_B configured to perform user initiated hold/resume using UPDATE 

• UE_B is registered in IMS_B via IMS_A 



Test Sequence: 


Step 






1 


User B calls User A 




2 


Verify that user A is informed of incoming call of User A 




3 


Verify that user B is informed that UE_A is ringing 




4 


User A answers call 




5 


Verify that user A is informed that call has been answered 




6 


Verify that user B is informed that call is established 




7 


User B puts call on hold 




8 


Verify that user A is informed that call is on hold 




9 


Verify that user B is informed that call is on hold 




10 


User B resumes call 




11 


Verify that user A is informed that call is resumed 




12 


Verify that user B is informed that call is resumed 




13 


User A ends call 




14 


Verify that user B is informed that call has ended 




15 


Verify that user A is informed that call has ended 


Conformance 
Criteria: 


Check 






1 


TP_IMS_5080_02 in CFW step 37B and 47B (UPDATE): 
ensure that { 

when { IMS A receives subsequent UPDATE from UE Bj 
then { IMS_A sends the UPDATE to IMS_B 
containing a P-Charging-Vectorheader 

containing an updated access-network-charging-info parameter} 

} 
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Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









35B 
36B 

37B 

38B 
39B 
40B 
41 B 

42B 
43B 



User B puts call on hold 



UPDATE 



UE_B sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 



UPDATE 



IMS A forwards UPDATE to IMS B 



UPDATE 



IMS B forwards UPDATE to IMS A 



UPDATE 



IMS A forwards UPDATE to UE A 



User A is informed that call on hold 



200 OK 



UE_A responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



44B 
45B 
46B 

47B 

48B 
49B 
50B 



200 OK 



IMS_A forwards the 200 OK response to UE_B 



User B resumes call 



UPDATE 



UE_B sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 



UPDATE 



IMS A forwards UPDATE to IMS B 



UPDATE 



IMS B forwards UPDATE to IMS A 



UPDATE 



IMS A forwards UPDATE to UE A 



User A is informed that call is resumed 



4.5.3.1 .2.6 Subsequent target refresh request (UPDATE), home user initiated 



Interoperability Test Description 


Identifier: 


TD IMS 0020 


Summary: 


IMS network handles subsequent UPDATES correctly in case of a user initiated call 
hold and resume when home caller puts a roaming user on hold and resumes call 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5120 02 


ES 283 003 [1], clause 5.4.3.3 H48 


Use Case ref.: 


UC 03 R 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using UPDATE 

• UE A registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using any user identity 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 
Criteria' 


Check 




\ 


TP IM^ PD n? in r.FW <;tpn anrl 4PA M IPDATFV 

in 1 1 vi o j ilu u c i 1 1 v_/ rvv o icu jun a i iu h^C/ \ lur \—/r\ i l j . 

ensure that { 

when { UE_A sends an UPDATE to UE_B } 
then { IMS_A receives the UPDATE from IMS_B 
not containing a topmost Route header 

containing the S-CSCF_SIP_URI 
containing a Record-Route header 
containing the S-CSCF SIP URI } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


I 


s 


E 


s 


E 


M 


M 


e 


A 


e 


B 


S 


S 


r 




r 




A 


B 


A 




B 









35A 
36A 

37A 
38A 

39A 
40A 
41A 

42A 
43A 
44A 
45A 
46A 
47A 

48A 
49A 

50A 
51A 
52A 

53A 
54A 
55A 
56A 



UPDATE 



UPDATE 



UPDATE 



UPDATE 



200 OK 



200 OK 



200 OK 



200 OK 



UPDATE 



UPDATE 



UPDATE 



UPDATE 



200 OK 



200 OK 



200 OK 



200 OK 



User A puts call on hold 



UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to IMS A 



IMS A forwards UPDATE to UE B 



User B is informed that call is on hold 



UE_B responds to with 200 OK indicating media 
attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is on hold 



User A resumes call 



UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to IMS A 



IMS A forwards UPDATE to UE B 



User B is informed that call is resumed 



UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is resumed 



4.5.3.1 .2.7 Call CANCEL due to loss of connectivity of calling user during call establishment 



Interoperability Test Description 


Identifier: 


TD IMS 0021 


Summary: 


IMS network sends CANCEL to call destination in case that the calling UE looses 




connectivity during dialog initiation 




Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 




TP IMS 5072 02 


ES 283 003 [1], clause 5.2.8.1.1 V 


Use Case ref.: 


UC 02 R 
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Interoperability Test Description 



Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_A and UE_B has IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UEA registered in IMS_A using any user identity 

• UE_B is registered in IMS_B via IMS_A using any user identity 

• IMS_A is supporting (simulated) PDF or PCRF like functionality 








Test Sequence: 


Step 






1 


User B calls User A 




2 


Verify that user A is informed of incoming call of User B 




4 


Verify that user B is informed that UE A is ringing 




5 


UE_B loses connectivity to IMS_A 




6 


Verify that user A is informed that call has been cancelled 






Conformance 
Criteria: 


Check 






1 


TP_IMS_5072_02 in CFW step 18 (CANCEL): 
ensure that { 

when { IMS A receives "an indication that UE B is no longer available" } 
then { IMS_A sends a CANCEL to IMS_B 
containing a Reason_header 
containing a status_code_parameter 
indicating "503 Service unavailable" 

} 

} 



Step 


Direction 


Message 


Comment 


10 


I 

; 

e 
i 
l 


J 

; 

4- 


I 

E 

/ 


J 


I 

c 
6 
t 

E 


J 

1 

J 


I 
E 
E 


J 

5 


1 

I 

c 

/ 


n 

\. 


r 

E 


n 

3 




User A is informed of incoming call of User B 


11 












} 

(; 




180 Ringing 


UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 






> 

« 


12 


180 Ringing 


IMS A forwards 180 Ringing response to 
IMS B 


13 


180 Ringing 


IMS B forwards the 1 80 Ringing response to 
IMS A 


14 


180 Ringing 


IMS A forwards the 1 80 Ringing response to 
UE B 


15 
16 








i 










User B is informed that UE_A is ringing 
UE_B looses connectivity 


17 




IMS_A is informed about UE B loosing 
connectivity 


18 












» 




CANCEL 


IMS_A sends CANCEL to IMS_B 


19 


i 


200 OK 


IMS_B responds with 200 OK to IMS_A 


20 


« 


CANCEL 


IMS_B forwards the CANCEL to IMS_A 


21 


} 


200 OK 


IMS_A responds with 200 OK to IMS_B 


22 


i 






CANCEL 


IMS_A forwards the CANCEL to UE_A 


23 
24 






* 


200 OK 


UE_A responds with 200 OK to IMS_A 

User A is informed that call has been cancelled 


25 




< 








» 




487 Request 
Terminated 


UE A sends 487 Request Terminated to IMS_A 


t 




> 


26 


ACK 


IMS_A responds with ACK to UE_A 


27 








487 Request 
Terminated 


IMS A forwards the 487 Request Terminated to 
IMS B 


28 


<; 


ACK 


IMS_B responds with ACK to IMS_A 
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4.5.3.1 .3 Subsequent Request Procedures - Originating Network 

4.5.3.1 .3.1 Call CANCEL by calling user 



Interoperability Test Description 


Identifier: 


TD IMS 0022 


Summary: 


IMS network handles correctly calling user cancelling call before its establishment 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5107 3 


ES 283 003 [1], clause 5.4.3.2 H49 


Use Case ref.: 


UC 02 I 



Pre-test 


• 


HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• 


UE_A and UE_B have IP bearers established to their respective IMS networks 






as per clause 4.2.1 




• 


UE_A is registered in IMS_A using any user identity 




• 


UE_B is registered in IMS_B using any user identity 



Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE_B is ringing 


4 


User A cancels call 


5 


Verify that user B is informed that call has been cancelled 




6 


Verify that user A is informed that call is terminated 








Conformance 
Criteria: 


Check 




1 


TP_IMS_5107_03 in CFW step 16 (CANCEL): 
ensure that { 
when { UE A sends CANCEL to UE Bj 
then { IMS_B receives the CANCEL 
containing no Route header 
indicating the S-CSCF SIP URI of IMS A 

} 
} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



10 



11 



12 

l3~ 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 180 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User A cancels the call 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



14 
HT 
16 
17 



19 
20 
21 

~22~ 
~23~ 

~24~ 
"25" 



26 



CANCEL 



UE A sends a CANCEL to IMS A 



200 OK 



IMS_A responds with a 200 OK to UE_A 



CANCEL 



IMS A forwards the CANCEL to IMS B 



200 OK 



IMS_B responds with a 200 OK to IMS_A 



CANCEL 



IMS B forwards the CANCEL to UE B 



200 OK 



UE_B responds with a 200 OK to IMS_B 



User B is informed that call has been cancelled 



487 Request 
Terminated 



UE B sends 487 Request Terminated to IMS_B 



ACK 



IMS_B responds with ACK to UE_B 



487 Request 
Terminated 



IMS_B forwards the 487 Request Terminated to 
IMS A 



ACK 



IMS_A responds with ACK to IMS_B 



487 Request 
Terminated 



IMS_A forwards the 487 Request Terminated to 
UE A 



ACK 



UE_A responds with ACK to IMS_A 



27 



User A is informed that call is terminated 



4.5.3.1 .3.2 Call CANCEL due to loss of connectivity of calling user during call 



Interoperability Test Description 


Identifier: 


TD IMS 0023 


Summary: 


IMS network ends call in case calling UE looses connectivity during a call 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5073 01 


ES 283 003 [1], clause 5.2.8.1.2 V 


Use Case ref.: 


UC 02 I 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS_B is supporting (simulated) PDF or PCRF like functionality 



Test Sequence: 


Step 






1 


User B calls User A 




2 


Verify that user A is informed of incoming call of User B 




3 


Verify that user B is informed that UE A is ringing 




4 


User A answers call 




5 


Verify that user B is presented that call in process 




6 


Verify that user A is informed that the call is in progress 




7 


UE_B looses connectivity 




8 


Verify that user A is informed that call has been ended 
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Interoperability Test Description 



Conformance 
Criteria: 


Check 




1 


TP_IMS_5073_01 in CFW step 23 (BYE): 
ensure that { 

when { IMS_B receives "an indication that UEB is no_longer_available" } 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the Contact_header_value of UEA and 
containing To_header 

indicating the initial 200_OK_To_value from UE A 
containing From_header 

indicating the initial INVITE_From_value from UE B and 
containinn Oall-ID header 

indicating the initial INVITE_Call_ld_value from UE B and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating "dialog specific routing information for UE A" and 
"further headers based on local policy or call release reason" 

} 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



13 
14 

l5~ 
16 
17 



19 
20 
21 
22 
23 
24 
25 
26 
27 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



BYE 



BYE 



200 OK 



200 OK 



User A answers call 



UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards the 200 OK response to UE_B 



User B is presented that call in process 



UE_B acknowledges the receipt of 200 OK for 
INVITE 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE A 



User A is informed that the call is in progress 



UE_B looses connectivity 



IMS B forwards BYE to IMS A 



IMS A forwards BYE to UE A 



User A is informed that call has ended 



UE A sends 200 OK for BYE 



IMS_A forwards 200 OK response to IMS_B 
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.3.1 .3.3 Call failure due to de-registration of calling user during call 



Interoperability Test Description 


Identifier: 


TD IMS 0024 


Summary: 


IMS network ends call in case calling UE is forcefully de-registered in IMS network during 
a call 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 




TP IMS 5139 01 


ES 283 003 [1], clause 5.4.5.1 .2 f 1 


Use Case ref.: 


UC 02 I 




Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 




per clause 4.2.1 






• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• There is an ongoing dialogue between UE A and UEB 



Test Sequence: 


Step 




1 


User A calls User B 




2 


Verify that user B is informed of incoming call of User A 




3 


Verify that user A is informed that UE B is ringing 




4 


User B answers call 




5 


Verify that User A is informed that call has been answered 




6 


Verify that User B is informed that the call is established 




7 


UE_A is forced to be de-registered in IMS_A 




8 


Verify that user B is informed that call has been ended 



Conformance 
Criteria: 


Check 




1 


TP_IMS_5139_01 in CFW step 23 (BYE): 
ensure that { 

when { IMS_A receives a "network internal indication that the lifetime 

of the last public user identity has expired"} 
then { IMS_A sends a BYE to UE_B 

containing a Request_URI set to Contact_header_value of UE B and 
containing a Tojneader set to 

the Tojneader of the 200_response to initial INVITE and 
containing a From_header set to 

the From_header of the initial INVITE and 
containing a Call-ID header set to 

the Call-ID Jneader of the initial INVITE and 
containing a CSeq_header set to 

"CSeq_header from the calling user incremented by one" and 
containing a Route_header set to 

"routeing information towards the called user as stored 

for the dialog" and 
containing "further headers, based on local policy or the 

requested session release reason" 
} 

} 
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Step 



Direction 



Message 



Comment 



u 


U 


I 
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U 
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s 
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E 
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A 


S 


S 


B 
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r 




A 


B 




r 


A 










B 



13 
14 

leT 

16 
17 



User B answers call 



200 OK 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 



18 



19 



20 
21 

~22~ 
23 
24 

~25~ 
26 
27 



ACK 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS_A forwards ACK to IMS_ 
S-CSCF 



ACK 



IMS B forwards ACK to UE B 



User B is informed that the call is established 



UE_A is forced to be de-registered in IMS_A 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS_B forwards 200 OK response to IMS_A 



4.5.3.1 .3.4 Subsequent target refresh request (INVITE) 



Interoperability Test Description 


Identifier: 


TD IMS 0025 


Summary: 


IMS network handles subsequent INVITEs correctly in case of a user initiated call hold 
and resume when home caller puts another home user on hold and resumes call 



Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5106 01 


ES 283 003 [1], clause 5.4.3.2 H42 


TP IMS 5121 02 


ES 283 003 [1], clause 5.4.3.3 H53 


Use Case ref.: 


UC 03 I 



: 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A configured to perform user initiated hold/resume using INVITE 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 


Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE_A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 
Criteria: 


Check 






1 


TP_IMS_5106_01 in CFW step 25A and 40A (INVITE): 
ensure that { 

when { UEA sends a subsequent INVITE to UE_B } 
then { IMS_B receives the subsequent INVITE 
containing a Record-Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
not containing Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 

not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo_header } 

} 




2 


TP_IMS_5121_02 (IMS_B) in CFW step 31 A and 46A (200 OK): 
ensure that { 
when { UEB sends a 2xx_response to UE A } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-network-charging-info _parameter and 
not containing a P-Access-Network-lnfo header } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 
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E 


M 


M 


E 
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A 


S 


S 
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A 


B 
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A 










B 



22A 
23A 



24A 



25A 
26A 

27A 
28A 

29A 
30A 

31 A 

32A 
33A 
34A 

35A 
36A 
37A 
38A 



39A 



40A 
41 A 

42A 
43A 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



User A puts call on hold 



UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMSB responds with a 100 Trying 
provisional response 



IMS B forwards INVITE to UE B 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed that call is on hold 



UE_B responds to INVITE with 200 OK 
indicating media attribute "recvonly" 



IMS B forwards 200 OK response to IMS A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is on hold 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to UE B 



User A resumes call 



UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS B responds with a 100 Trying 
provisional response 



IMS B forwards INVITE to UE B 



UE_B optionally responds with a 100 Trying 
provisional response 



ETSI 



97 



ETSI TS 186 011-2 V2.2.1 (2009-03) 



Step 


Direction 


Message 


Comment 




U 


U 






1 




U 


U 
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s 
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A 


S 


S 


B 


e 








i 








A 


B 








r 








A 


















B 






44A 












» 






User B is informed that call is resumed 


45A 
























200 OK 


UE_B responds to INVITE with 200 OK 






























indicating media attribute "sendrecv" 


46A 


























200 OK 


IMS B forwards 200 OK response to IMS A 












<— 














47A 
48A 


























200 OK 


IMS_A forwards the 200 OK response to UE_A 
User A is informed that call is resumed 




<— 





















4.5.3.1.3.5 



Subsequent target refresh request (UPDATE) 



Interoperability Test Description 


Identifier: 


TD IMS 0026 


Summary: 


IMS network handles subsequent UPDATES correctly in case of a user initiated call 
hold and resume when home caller puts another home user on hold and resumes call 


Configuration: 


CF INT CALL 


SUT 


IMS_A, IMS_B 


References 


Test Purpose 


Specification Reference 




TP IMS 5106 02 


ES 283 003 [1], clause 5.4.3.2 H42 




TP IMS 5121 02 


ES 283 003 [1], clause 5.4.3.3 H53 


Use Case ref.: 


UC 03 I 









Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A configured to perform user initiated hold/resume using UPDATE 
UE_A is registered in IMS_A using any user identity 

UE_B is registered in IMS_B using any user identity 



Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE_A is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that call is established 


7 


User A puts call on hold 


8 


Verify that user B is informed that call is on hold 


9 


Verify that user A is informed that call is on hold 


10 


User A resumes call 


11 


Verify that user B is informed that call is resumed 


12 


Verify that user A is informed that call is resumed 


13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 








Conformance 
Criteria: 


Check 




1 


TP_IMS_51 06_02 (IMS_A) in CFW step 24A and 33A (UPDATE): 
ensure that { 
when { UE A sends an UPDATE to UE Bj 
then { IMS_B receives the UPDATE 

containing a Record-Route header 

containing the S-CSCF_SIP_URI of IMS_A and 
not containing Route header 

indicating the S-CSCF_SIP_URI of IMS_A and 
containing a P-Charging-Vector_header 
not containing a access-network-charging-info_parameter 
and 

not containing a P-Access-Network-lnfo header } 

} 
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Interoperability Test Description 




2 


TP_IMS_5121_02 (IMS_B) in CFW step 28A and 37A (200 OK): 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-network-charging-info _parameter and 
not containing a P-Access-Network-lnfo header } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



22A 
23A 

24A 

25A 
26A 
27A 

28A 

29A 

30A 
31A 
32A 

33A 

34A 
35A 
36A 

37A 

38A 
39A 



UPDATE 



UPDATE 



UPDATE 



200 OK 



200 OK 



200 OK 



UPDATE 



UPDATE 



UPDATE 



200 OK 



200 OK 



200 OK 



User A puts call on hold 



UE_A sends UPDATE message indicating 
media attribute "sendonly" (Call Hold) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to UE B 



User B is informed that call is on hold 



UE_B responds to UPDATE with 200 OK 
indicating media attribute "recvonly" 



IMSB forwards 200 OK response to IMSA 



IMS_A P-CSCF forwards the 200 OK response 
to UE A 



User A is informed that call is on hold 



User A resumes call 



UE_A sends UPDATE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS A forwards UPDATE to IMS B 



IMS B forwards UPDATE to UE B 



User B is informed that call is resumed 



UE_B responds to UPDATE with 200 OK 
indicating media attribute "sendrecv" 



IMS B forwards 200 OK response to IMS A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call is resumed 



4.5.3.1 .4 Subsequent Request Procedures - Terminating Network 



Interoperability Test Description 


Identifier: 


TD IMS 0027 


Summary: 


IMS network ends call in case called UE looses connectivity during a call 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5074 01 


ES 283 003 [1 ], clause 5.2.8.1 .2 V 1 


Use Case ref.: 


UC 02 I 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE A and UE B has IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 
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Interoperability Test Description 



Test Sequence: 


Step 






1 


User A calls User B 




2 


Verify that user B is informed of incoming call of user A 




3 


Verify that user A is informed that UE_B is ringing 




4 


User B answers call 




5 


Verify that User A is informed that call has been answered 




6 


Verify that User B is informed that the call is established 




7 


UE_B looses connectivity 




8 


Verify that user A is informed that call has been ended 








Conformance 


Check 




Criteria: 








1 


TP_IMS_5074_01 in CFW step 23 (BYE): 
ensure that { 

when { IMS B receives 'an indication that UE B is no longer available' } 
then { IMS_B sends a BYE to IMS_A 
containing Request_URI 

indicating the Contact_header_value of UEA and 
containing To_header 

indicating the initial INVITE_To_value from UE A 
containing From_header 

indicating the initial 200_OK_From_value from UE B and 
containing Call-ID header 

indicating the initial INVITE_Call_ld_value from UE A and 
containing CSeq_header 

indicating an incremented Sequence_Number and 
containing Route_header 

indicating "dialog specific routing information for UE A" and 
"further headers based on local policy or call release reason" 

} 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 
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r 




A 


B 




r 


A 










B 



13 
14 

l5~ 
16 
17 



19 
20 
21 

~22~ 
23 
24 

~25~ 
26 
27 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



BYE 



BYE 



200 OK 



200 OK 



User B answers call 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to UE B 



User B is informed that the call is established 



UE_B looses connectivity 

IMS_B sends a BYE to IMS_A 



IMS_A forwards the BYE response to UE_A 



UE A is informed that call has ended 



UE_A responds to the BYE with 200 OK 



IMS_A forwards the 200 OK response to IMS_B 
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4.5.3.1 .5 Dialogue Procedures - Topology Hiding 

4.5.3.1.5.1 Normal call 



Interoperability Test Description 


Identifier: 


TD IMS 0028 


Summary: 


IMS network handles basic call with topology hiding correctly 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5135 01 


ES 283 003 [1], clause 5.10.4.1 f7 


TP IMS 5137 01 


ES 283 003 [1], clause 5.10.4.2 V 


TP IMS 5404 01 


ES 283 003 [1], clause 5.10.2.2 V 


TP IMS 5408 01 


ES 283 003 [1], clause 5.10.2.3 V 


TP IMS 5408 03 


ES 283 003 [1], clause 5.10.2.3 1f1 


TP IMS 5414 01 


ES 283 003 [1], clause 5.10.3.2 V 


TP IMS 5137 02 


ES 283 003 [1], clause 5.10.4.2 V 


TP IMS 5137 03 


ES 283 003 [1], clause 5.10.4.2 V 


Use Case ref.: 


UC 02 I 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS_A is configured for topology hiding 



Test Sequence: 


Step 




1 


User A calls user B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE_B is ringing 


4 


User B answers the call 


5 


Verify that user A is informed that call has been answered 


6 


User B is informed that the call is established 


7 


User A ends the call 


8 


Verify with UE_B that call has been released 


9 


Verify with UE_A that call has been released 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5135_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE B sends a initial INVITE to IMS A } 
then { IMS_A sends the initial INVITE to IMS_B 

containing an additional topmost Record-Route header 
indicating the IBCF SIP URI of IMS A } 

} 


2 


TP_IMS_5137_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE A sends an initial INVITE to UE B} 
then { IMS_A sends the INVITE to IMS_B 
containing a Via_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

} 
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Interoperability Test Description 




3 


TP_IMS_5404_01 in CFW step 4 (INVITE): 
ensure that { 
when { UE_A sends an initial INVITE to UE_B 

containing a P-Charging-Vector_header and 
containing a P-Charging-Function-Addresses header } 
then { IMS_A sends the INVITE 

not containing (a P-Charging-Vector_header and 

a P-Charging-Function-Addresses header) } 

} 




4 


TP_IMS_5408_01 in CFW step 19 (ACK): 
ensure that { 
when { UE A sends an ACK to UE Bj 
then { IMS_A sends the ACK to IMS_B 
containing a Via_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

} 




5 


TP_IMS_5408_03 in CFW step 24A (BYE): 
ensure that { 
when { UE A sends a BYE to UE B} 
then { IMS_A sends the BYE to IMS_B 
containing a Viajneader 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

} 




6 


TP_IMS_5414_01 in CFW step 5 (100 Trying): 
ensure that { 

when {UE A sends an initial INVITE to UE B and 
IMS_A sends the INVITE to IMS_B } 

then { IMS B sends a 100 response to IMS A } 

} 




7 


TP_IMS_5137_02 in CFW step 10 (180 Ringing): 
ensure that { 
when { UEB sends a 1xx_response to UEA } 
then { IMS_B sends the Ixx response to IMS_A 
containing Viajneader 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

} 




8 


TP_IMS_5137_03 in CFW step 15and28A (200 OK): 
ensure that { 
when { UE B sends a 2xx_response to UE A } 
then { IMS_B sends the 2xx_response to IMS_A 
containing a Viajneader 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record-Routejneader 
containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

I 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 
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A 
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S 


B 
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r 




A 


B 




r 


A 










B 



10 



11 



12 
14 

jjjT 

16 
17 



19 

20 

21 
22A 
23A 
24A 
25A 
26A 
27A 
28A 
29A 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMSB responds with a 100 Trying 
provisional response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS B forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



200 OK 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



200 OK 



IMS B forwards 200 OK response to IMSA 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



ACK 



Us 



informed that call has been answered 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to UE B 



User B is informed that the call is established 



User A ends call 



BYE 



UE A releases the call with BYE 



BYE 



IMS A forwards BYE to IMS B 



BYE 



IMS B forwards BYE to UE B 



User B is informed that call has ended 



200 OK 



UE B sends 200 OK for BYE 



200 OK 



IMS B forwards 200 OK response to IMS A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 
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4.5.3.1 .5.2 CANCEL call by calling user 



Interoperability Test Description 


Iripntif ipi" 

IUCI 1 11 1 ICI ■ 


TD IMS 0029 


OL1 1 1 1 1 1 1 a 1 y . 


IMS network handles calling user cancelling call correctly before its establishment with 
topology hiding 


Configuration: 


CF INT CALL 


SUT 


IMS A and IMS B 




Test Purpose 


Specification Reference 




TP IMS 5408 02 


ES 283 003 [1], clause 5.10.2.3 1f1 


Use Case ref.: 


UC 02 1 








Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_A and UE_B have IP bearers established to their respective IMS networks 




as per clause 4.2.1 






• UE_A is registered in IMS_A using any user identity 

• UE_B is registered in IMS_B using any user identity 

• IMS A is configured for topology hiding 



Test Sequence: 


Step 




1 


User A calls User B 


2 


Verify that user B is informed of incoming call of User A 


3 


Verify that user A is informed that UE B is ringing 


4 


User A cancels call 


5 


Verify that user B is informed that call has been cancelled 


6 


Verify that user A is informed that call is terminated 


Conformance 
Criteria: 


Check 




1 


TP_IMS_5408_02 in CFW step 16 (CANCEL): 
ensure that { 
when { UE A sends a CANCEL to UE B} 
then { IMS_A sends the CANCEL to IMS_B 
containing a Via_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 
containing (encrypted_consecutive_header_enthes and 
a tokenized-by parameter) } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


1 


1 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired medias and codecs that 
UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 
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Step 



Direction 



Message 



Comment 



u 


U 


I 


I 


U 


U 


s 


E 


M 


M 


E 


s 


e 


A 


S 


S 


B 


e 


r 




A 


B 




r 


A 










B 



10 



11 



12 
13 
14 
l5~ 
16 
17 



19 
20 
21 

~22~ 
~23~ 

~24~ 
~25~ 



26 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User A cancels the call 



CANCEL 



UE A sends a CANCEL to IMS A 



200 OK 



IMS_A responds with 200 OK to UE_A 



CANCEL 



IMS A forwards the CANCEL to IMS B 



200 OK 



IMS_B responds with 200 OK to IMS_A 



CANCEL 



IMS B forwards the CANCEL to UE B 



200 OK 



UE_B responds with 200 OK to IMS_B 



User B is informed that call has been cancelled 



487 Request 
Terminated 



UE B sends 487 Request Terminated to IMS_B 



ACK 



IMS_B responds with ACK to UE_B 



487 Request 
Terminated 



IMS_B forwards the 487 Request Terminated to 
IMS A 



ACK 



IMS_A responds with ACK to IMS_B 



487 Request 
Terminated 



IMS_A forwards the 487 Request Terminated to 
UE A 



ACK 



UE_A responds with ACK to IMS_A 



27 



User A is informed that call is terminated 



4.5.3.1.5.3 



Normal call with hold/resume 



Interoperability Test Description 


Identifier: 


TD IMS 0030 


Summary: 


IMS network handles user initiated call hold and resume correctly when a home caller 
puts a roaming user on hold and resumes call with topology hiding 


Configuration: 


CF ROAM CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5408 04 


ES 283 003 [1], clause 5.10.2.3 V 


Use Case ref.: 


UC 03 R 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A configured to perform user initiated hold/resume using INVITE 

UE_A is registered in IMS_A using any user identity 

UE_B is registered via IMS A in IMS_B using any user identity 

IMS_A is configured for topology hiding 



Test Sequence: 


Step 






1 




User A calls User B 




2 


Verify that user B is informed of incoming call of User A 




3 


Verify that user A is informed that UE A is ringing 




4 


User B answers call 




5 


Verify that user A is informed that call has been answered 




6 


Verify that user B is informed that call is established 




7 


User A puts call on hold 




8 


Verify that user B is informed that call is on hold 




9 


Verify that user A is informed that call is on hold 




10 


User A resumes call 




11 


Verify that user B is informed that call is resumed 




12 


Verify that user A is informed that call is resumed 
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Interoperability Test Description 




13 


User A ends call 


14 


Verify that user B is informed that call has ended 


15 


Verify that user A is informed that call has ended 






Conformance 
Criteria: 


Check 




1 


TP_IMS_5408_04 in CFW step 38A and 57A (INVITE): 
ensure that { 

when { UE A sends a subsequent INVITE to UE B } 
then { IMS_A sends the INVITE to IMS_B 
containing a Via_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Record-Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by_parameter) and 
containing a Route_header 
containing (encrypted_consecutive_header_entries and 
a tokenized-by parameter) } 

} 



Step 



Direction 



u 


U 


U 


U 


I 


s 


E 


s 


E 


M 


e 


A 


e 


B 


S 


r 




r 




A 


A 




B 







Message 



Comment 



I 

M 
S 
B 



34 
35A 
36A 



37A 



38A 

39A 

40A 
41A 

42A 
43A 

44A 
45A 

46A 
47A 
48A 
49A 

50A 
51A 
52A 
53A 
54A 
55A 



56A 



57A 

58A 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



INVITE 



100 Trying 



INVITE 



100 Trying 



User B is presented that call is in progress 



User A puts call on hold 



UE_A sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards INVITE to IMS A 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to UE B 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed that call is on hold 



UE_B responds to INVITE with 200 OK 
indicating media attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS_A forwards the 200 OK response to UE_A 



UE_A acknowledges the receipt of 200 OK for 
INVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE B 



User A is informed that call is on hold 



User A resumes call 



UE_A sends relNVITE message indicating 
media attribute "sendrecv" (Call Resume) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 
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Step 



Direction 
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Message 



Comment 



I 

M 
S 
B 



59A 



60A 



61A 



62A 



63A 



INVITE 



IMS B forwards INVITE to IMS A 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed that call is resumed 



4.5.4 Messaging 

4.5.4.1 Messaging with SIP URI public identities 



Interoperability Test Description 


Identifier: 


TD IMS 0031 


Summary: 


IMS network handles messaging with SIP identity correctly without topology hiding 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 05 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5097 06 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5117 02 


ES 283 003 [1], clause 5.4.3.3 ^44 


TP IMS 5118 01 


ES 283 003 [1], clause 5.4.3.3 |45 


Use Case ref.: 


UC 05 I 







Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A is registered in IMS_A using userSIP_priv according to table 1 
UE_B is registered in IMS_B using any user identity 
IMS_A is within the trust domain of IMS_B 
UE_A and UE_B registered with SIP URI public identities 
IMS_A not configured for topology hiding 









Test Sequence: 


Step 






1 


User A sends message to user B 




2 


Verify that user B receives message from user A 






Conformance 


Check 




Criteria: 


1 


TP_IMS_5097_05 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE A sends a MESSAGE to UE B } 
then { IMS_B receives the MESSAGE 
not containing a Route header 

indicating the S-CSCF_SIP_URI of IMS_A 
containing a P-Charging-Vector header 
(containing an icidjparameter and 
containing a orig-ioi_parameter indicating IMS_A and 
not containing a term-ioijparameter) and 
containing a P-Charging-Vector header 
not containing a access-network-charging-info parameter } 

} 
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Interoperability Test Description 




2 


TP_IMS_5097_06 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel URI } 
then { IMS_B receives the MESSAGE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel URI } 

} 




3 


TP_IMS_51 1 7_02 in CFW step 7 (200 OK) 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-network-charging-info jparameter and 
not containing a P-Access-Network-lnfo header } 

} 




4 


TP_IMS_51 1 8_01 in CFW step 7 (200 OK) 
ensure that { 
when { UE B sends 200_response to UE A } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioi jparameter 

indicating operator ^identifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B } 

} 



Step 



Direction 



Message 



Comment 
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B 



User A sends an instant message to user B 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS A sends MESSAGE to IMS B 



MESSAGE 



200 OK 



IMS B sends MESSAGE to UE B 



UE B sends 200 OK to IMS B 



200 OK 



IMS B sends 200 OK to IMS A 



200 OK 



IMS_A sends 200 OK to UE_A 
Optional: User A is presented a 
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.5.4.2 Messaging with TEL URI identities 



Interoperability Test Description 


Identifier: 


TD IMS 0032 


Summary: 


IMS network handles messaging with TEL URI identities correctly 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 07 


ES 283 003 [1], clause 5.4.3.2 |1 


TP IMS 5117 02 


ES 283 003 [1], clause 5.4.3.3 H44 


TP IMS 5118 01 


ES 283 003 [1], clause 5.4.3.3 H45 


TP IMS 5117 06 


ES 283 003 [1], clause 5.4.3.3 ^44 


Use Case ref.: 


UC 05 I 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using userTEL_priv according to table 1 

• UE_B is registered in IMS_B using userTEL_priv according to table 1 

• IMS A is within the trust domain of IMS B 




Test Sequence: 


Step 




1 


User A sends message to User B (i.e. userTEL in IMS_B) 


2 


Verify that user B receives message from user A 








Conformance 
Criteria: 


Check 




1 


TP_IMS_5097_07 in CFW step 3 (MESSAGE) 
ensure that { 
when { UE_A sends a MESSAGE to UE_B 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_B receives the MESSAGE 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI } 

} 


2 


TP_IMS_51 1 7_02 in CFW step 7 (200 OK) 
ensure that { 
when { UEB sends a 2xx_response to UEA } 
then { IMS_A receives the 2xx_response 

containing a P-Charging-Vector_header 

not containing a access-network-charging-info _parameter and 
not containing a P-Access-Network-lnfo header } 

} 


3 


TP_IMS_51 1 8_01 in CFW step 7 (200 OK) 
ensure that { 
when { UE B sends 200_response to UE A } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioijparameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B } 

} 
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Interoperability Test Description 




4 


TP_IMS_51 1 7_06 in CFW step 7 (200 OK) 
ensure that { 
when { UE B sends a 2xx_response to UE A 

not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI } 
then { IMS_A receives the 2xx_response 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity and 
containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP UFtl } 

} 



Step 



Direction 



Message 



Comment 
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User A sends an instant message to user B 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS A sends MESSAGE to IMS B 



MESSAGE 



IMS B sends MESSAGE to UE B 



User B is informed about the instant message 



200 OK 



UE B sends 200 OK to IMS B 



200 OK 



IMS B sends 200 OK to IMS A 



200 OK 



IMS A sends 200 OK to UE A 



Optional: User A is presented a delivery report 



4.5.4.3 



Messaging with DNS/ENUM lookup procedure 



Interoperability Test Description 


Identifier: 


TD IMS 0033 


Summary: 


IMS network handles messaging with DNS/ENUM lookup procedure correctly 


Configuration: 


CF INT CALL 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 08 


ES 283 003 [1], clause 5.4.3.2 |1 


TP IMS 5117 04 


ES 283 003 [1], clause 5.4.3.3 H44 


Use Case ref.: 


UC 05 I 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 
UE_B is registered in IMS_B using userTEL_priv according to table 1 
IMS_A is within the trust domain of IMS_B 
Common DNS is configured with a DNS/ENUM entry mapping 











Test Sequence: 


Step 






1 


User A sends message to user B's Tel URI (i.e. userTEL in IMS_B) 




2 


Verify that user B receives message from user A 
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Interoperability Test Description 



Conformance 


Check 




Criteria' 


\ 


TP IM^ 5097 Oft in P.FW qtpn 5 (MFSSAfiR 

i i iivio vjui?/ v/O ill urvv oicu \j \ ivi cuun\jr_ j 






C7i lOU 1 LI let L J 






M/hpn / 1 IF A qpnrfc a MF^^tAHF tn 1 IF R 

Vvl it?/ / J (_/ L_ /I oCTi IUO CI IV II— ^_7L_ iU LJ 1— l—J 
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inriimtinn £i TpI I JRI J 






//)pn / //MS 4 spnds a D/VS Ouprv tn DNS 






containing the Tei_URI_E. 164_Number } 






when { IMS_A receives DNS_Response 






mnfaininn a frJAPTR Rpqdi irep Rpmrci 

\j\Jt 1 Idl 1 II 1 /y CI ' V/l i / / 1 I I^OLfUf / I^Ot" u 






indicating the SIP URI of UE B } 






then { IMS A sends the MESSAGE to IMS B 






containing a Request URI 






indicating a SIP URI 






containing a P-Charging-Vector header 






not containing a access-network-charging-info _parameter } 

i 




2 


TP IMS 5117 04 in CFW steD 9 (200 OM 






pn^nrp thfit { 

\sii\j\ji\s hick, j 






when { UE B sends a 2xx_response to UE A 






nnt rnnfaininfl £i P-Prpfprrpd-lrlpntitv hparfpr nr 
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containing a P-Preferred-ldentity_header 






not indicating a Tel_URI} 






then { IMS_A receives the 2xx_response 






containing a P-Asserted-ldentity_header 






indicating the default_registered_public_identity and 






containing a P-Asserted-ldentity_header 






indicating a Tel URI } 

} 



Step 
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10 

11 



User A sends an instant message 



MESSAGE 



UE A sends MESSAGE to IMS A 



DNS QUERY 



DNS 

RESPONSE 



IMS_A sends DNS QUERY to common DNS 
containing E.164 TEL URI 



Common DNS sends DNS RESPONSE 
containing NAPTR resource record to IMS_A 



MESSAGE 



IMS A sends MESSAGE to IMS B containing 
Request URI which indicates a SIP URI 



MESSAGE 



IMS B sends MESSAGE to UE B 



User B is informed about the instant message 



200 OK 



UE B sends 200 OK to IMS B 



200 OK 



IMS B sends 200 OK to IMS A 



200 OK 



IMS A sends 200 OK to UE A 



Optional: User A is presented a delivery report 
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.5.4.4 Messaging when roaming 



Interoperability Test Description 


Identifier: 


TD IMS 0034 


Summary: 


IMS network handles messaging while roaming correctly 


Configuration: 


CF ROAM CALL 


SUT 


IMS A and IMS B 


References 


Test Purpose 


Specification Reference 




TP IMS 5108 02 


ES 283 003 [1], clause 5.4.3.3 V 




TP IMS 5118 01 


ES 283 003 [1], clause 5.4.3.3 H45 




TP IMS 5050 01 


ES 283 003 [1], clause 5.2.6.3 H46 


Use Case ref.: 


UC 05 R 



: 



Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_A and UE_B have IP bearers established to their respective IMS networks as 




per clause 4.2.1 




• UE_A is registered in IMS_A using any user identity 




• UE_B is registered in IMS_B via IMS_A using any user identity 



Test Sequence: 


Step 






1 


User A sends message to user B 




2 


Verify that user B receives message from user A 










Conformance 


Check 




Criteria: 


1 


TP_IMS_5108_02 in CFW step 4 (MESSAGE) 
ensure that { 
when { UE A sends a MESSAGE to UE B 
IMS_A sends the MESSAGE to IMS_B 
containing a P-Charging-Vector_header 
containing an icid_parameter } 
then { IMS_B sends the MESSAGE to IMS_A 
containing no Route header and 

indicating the S-CSCF_SIP_URI of IMS_B and 
containing a P-Charging-Vector_header 
containing the same icidjparameter and 
not containing ioijparameters 
containing a Record-Route header 
containing the S-CSCF SIP URI of IMS B } 

} 




2 


TP_IMS_51 1 8_01 in CFW step 9 (200 OK) 
ensure that { 
when { UE B sends 200_response to UEA } 
then { IMS_A receives the 200_response 

containing a P-Charging-Vector_header 
containing a orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
containing a term-ioi_parameter 
indicating operator identifier of IMS B } 

} 




3 


TP_IMS_5050_01 in CFW step 3 (MESSAGE) 
ensure that { 
when { IMS A receives a MESSAGE from UE B } 
then { IMS_A sends the MESSAGE to IMS_B 
containing a Route_header 
indicating the "list of Service Route header URIs 
from registration" and 
not containing a P-Preferred-ldentity_header and 
containing P-Asserted-ldentity_header 

containing an address of UE A and 
containing the P-Charging-Vector_header 
containing an icid parameter } 

} 
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10 

11 



User A sends an instant message to user B 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS A sends MESSAGE to IMS B 



MESSAGE 



IMS B sends MESSAGE to IMS A 



MESSAGE 



IMS A sends MESSAGE to UE B 



User B is informed about the instant message 



200 OK 



UE B sends 200 OK to IMS A 



200 OK 



IMS A sends 200 OK to IMS B 



200 OK 



IMS B sends 200 OK to IMS A 



200 OK 



IMS A sends 200 OK to UE A 



Optional: User A is presented a delivery report 



4.5.4.5 Messaging with receiving user not registered 



Interoperability Test Description 


Identifier: 


TD IMS 0035 


Summary: 


IMS network handles messaging correctly when receiving user is not registered 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5114 02 


ES 283 003 [1], clause 5.4.3.3 H34 


Use Case ref.: 


UC 05 I 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks as 
per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B is not registered in IMS_B 

• IMS_B is not configured with any filter criteria to contact "any AS" 


Test Sequence: 


Step 




1 


User A sends message to a valid user B identity 


2 


Verify that user A is informed that user B could not be reached 



Conformance 


Check 




Criteria: 


1 


TP_IMS_51 14_02 in CFW step 5 (4xx Response) 
ensure that { 
when { UE A sends a MESSAGE to UE B and 

IMS_A sends the MESSAGE to IMS_B } 
then { IMS B sends a 4xx response to IMS A 
} 

} 
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User A sends an instant message to NON 
registered user B 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS A sends MESSAGE to IMS B 



IMS_B detects that user B is not registered 



4xx 

Response 



IMS B sends 4xx Response to IMS A 



4xx 

Response 



IMS_A sends 4xx Response to UE_A 



User A is informed that user B could not be 
reached 



4.5.4.6 



Messaging with receiving user barred 



Interoperability Test Description 


Identifier: 


TD IMS 0036 


Summary: 


IMS network handles messaging correctly when receiving user has been barred 


Configuration: 


CF INT CALL 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5108 06 


ES 283 003 [1], clause 5.4.3.3 1f1 


Use Case ref.: 


UC 05 I 



Pre-test 
conditions: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks as 

per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 
UE_B is registered in IMS_B using any user identity 
User B is barred in IMS B 



Test Sequence: 


Step 




1 


User A sends message to User B 


2 


Verify that user A is informed that user B could not be reached 






Conformance 
Criteria: 


Check 




1 


TP_IMS_5108_06 in CFW step 5 (404 Response) 
ensure that { 
when { UE A sends a MESSAGE to UE B and 
IMS_A sends the MESSAGE to IMS_B 
containing a Request_URI 

indicating a barred_user in IMS_B } 
then { IMS B sends 404 response to IMS A } 

} 
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Step 



Direction 
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User A sends an instant message to registered 
user B 



MESSAGE 



UE A sends MESSAGE to IMS A 



MESSAGE 



IMS A sends MESSAGE to IMS B 



IMS B detects that user B has been barred 



404 Not 
Found 



IMS B sends 404 Response to IMS A 



404 Note 
Found 



IMS_A sends 404 Response to UE_A 



Optional: User A is informed that user B could 
not be reached 



4.5.5 Supplementary Services 

4.5.5.1 Supplementary Service HOLD with AS 



Interoperability Test Description 


Identifier: 


TD IMS 0037 


Summary: 


IMS network supports properly application services based on the example of the HOLD 
supplementary service 


Configuration: 


CF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 




TP IMS 5310 01 


ES 283 003 [1], clause 5.4.6.1.2 V 




TP IMS 5312 01 


ES 283 003 [1], clause 5.4.6.1.3 1f1 




TP IMS 5308 02 


ES 283 003 [1], clause 5.4.4.2.2 1f2 


Use Case ref.: 


UC 10 R 



Pre-test 
conditions: 



Test Sequence: 



HSS of IMS_A and of IMS B is configured according to table 1 

UE_A and UE_B have IP bearers established to their respective IMS networks 

as per clause 4.2.1 

UE_A is registered in IMS_A using any user identity 

UE_B is registered in IMS_B via IMS_A using userHOLD identity according to 
table 1 

IMS_B is configured to contact AS_B (HOLD) 
UE B is subscribed to HOLD service 
AS B in same trust domain as IMS B 



Step 



10 



11 



12 



13 



14 



15 



User A calls User B (i.e. userHOLD in IMS_B) 



Verify that user B is informed of incoming call of User A 



Verify that user A is informed that UE_B is ringing 



User B answers call 



Verify that user A is informed that call has been answered 



Verify that user B is informed that call is established 



User B puts call on hold 



Verify that user A is informed that call on hold with AS tone 



Verify that user B is informed that call on hold 



User B resumes call 



Verify that user A is informed that call is resumed 



Verify that user B is informed that call is resumed 



User A ends call 



Verify that user B is informed that call has ended 



Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 
Criteria: 


Check 




1 


TP_IMS_5310_01 in CFW step 30 and Step 32 (INVITE) 
ensure that { 

when { IMS_A sends a subsequent INVITE to IMS_B 
containing a P-Charging-Vector_header 

Kjwi new it i /y cti i d00C70o tiavvuin Kji icii yn 'y iiiikj kjoi cti i lao cti ikj 

containing a P-Access-Network-lnfo header 

I 

then { IMS_B sends the INVITE to AS_B 

containing a P-Charging-Vector_header 
containing an access-network-charging-info_parameter and 
containing a P-Access-Network-lnfo header 

} 

} 




3 


TP_IMS_5312_01 in CFW step 41 and Step 43 (200 OK) 
ensure that { 

whpn / IMS R rprpivpQ a POD rpcinniTZf* frnm 1 IF R 
containing a P-Charging-Vector_header 

containing an access-network-charging-info parameter 

} 

then { IMS_B sends the 200_response to AS_B 
containing a P-Charging-Vector_header 

containing a access-network-charging-info parameter 

} 

} 


4 


TP_IMS_5308_02 in CFW step 70 (200 OK) 
ensure that { 
when { IUT receives a 200 response from UE A 
containing a P-Charging-Vector_header 
including an access-network-charging-info parameter 

} 

then { IUT sends the 200_response to AS_A 
containing a P-Charging-Vector header 
including an access-network-charging-info parameter 

} 

} 
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27 



28 



29 



30 



31 



32 



33 



35 



35 



36 



37 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



User B puts call on hold 



UE_B sends relNVITE message indicating 
media attribute "sendonly" (Call Hold) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B sends relNVITE to AS B 



AS_B optionally responds with a 100 Trying 
provisional response 



AS B sends relNVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards relNVITE to IMS A 



IMS_A responds with a 100 Trying provisional 
response 
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Step 



Direction 



Message 



Comment 
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38 



39 



40 



41 



42 



43 



44 



45 



46 



47 



48 



49 



50 



51 



52 



53 



54 



55 



56 



57 



58 



59 



60 



61 



62 



63 



64 



65 



66 



67 



68 



INVITE 



100 Trying 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



200 OK 



ACK 



ACK 



ACK 



ACK 



ACK 



ACK 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



200 OK 



IMS A forwards relNVITE to UE A 



UE A optionally responds with a 1 00 Trying 
provisional response 



User A is informed that call is on hold with AS 

UE_A responds to relNVITE with 200 OK 
indicating media attribute "recvonly" 



IMS_A forwards 200 OK response to IMS_B 



IMS B forwards 200 OK response to AS B 



AS_B forwards 200 OK response to IMS_B 



IMS_B forwards 200 OK response to IMS_A 



IMS A forward the 200 OK to UE B 



User B is informed that the call is on hold 



UE_B acknowledges the receipt of 200 OK for 
relNVITE 



IMS A forwards ACK to IMS B 



IMS B forwards ACK to AS B 



AS B forwards ACK to IMS B 



IMS B forwards ACK to IMS A 



IMS A forwards ACK to UE B 



User B resumes call 



UE B sends second relNVITE message 
indicating media attribute "sendrecv" (Call 
Resume) 



IMS_A responds with a 100 Trying provisional 
response 



IMS A sends relNVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B sends relNVITE to AS B 



AS_B optionally responds with a 100 Trying 
provisional response 



AS B forwards INVITE to IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B sends relNVITE to IMS A 



IMS_A responds with a 100 Trying provisional 
response 



IMS A forwards relNVITE to UE A 



UE_A optionally responds with a 100 Trying 
provisional response 



UE_A sends the 200 OK indicating media 
attribute "sendrecv" to IMS A 
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Step 



Direction 



Message 



Comment 
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69 



70 



71 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS B forwards 200 OK response to AS B 



200 OK 



AS B forwards the 200 OK for INVITE 



72 



73 



74 



200 OK 



IMS B forwards 200 OK to IMS A 



200 OK 



IMS A forwards 200 OK to UE B 



User B is informed that call is resumed 



4.5.5.2 



Supplementary Service OIP with AS 



Interoperability Test Description 


Identifier: 


TD IMS 0038 


Summary: 


IMS network supports properly application services based on the example of the OIP 
supplementary service 


Configuration: 


CF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 02 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5097 03 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5097 09 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5108 03 


ES 283 003 [1], clause 5.4.3.3 V 


TP IMS 5118 02 


ES 283 003 [1], clause 5.4.3.3 1145 


Use Case ref.: 


UC 08 R 



Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE B is registered in IMS B via IMS A using userOIP identity according to 
table 1 

• IMS_B is configured to contact AS_B (OIP) 

• UE B is subscribed to OIP service 






Test Sequence: 


Step 




1 


User A calls User B (i.e. userOIP in IMS_B) 


2 


Verify that user B is informed of incoming call of User A, user A's identity is 
displayed 


3 


Verify that user A is informed that UE B is ringing 


4 


User B answers call 


5 


Verify that user A is informed that call has been answered 


6 


Verify that user B is informed that the call is established 


7 


User A ends call 


8 


Verify that user B is informed that call has ended 


9 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5097_02 in CFW step 4 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from UEA addressed_to UEB 
not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
not indicating a Tel URI of UE A } 
then { IUT sends the initial INVITE to IMS_B 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE A 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel URI of UE A} 

} 




2 


TP_IMS_5097_03 in CFW step 4 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from UE A addressed_to UE B 
not containing a P-Preferred-ldentity_header or 
containing a P-Preferred-ldentity_header 
indicating a Tel_URI of UE_A} 
then { IUT sends the initial INVITE to IMS_B 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE A 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI of UE A} 

} 




3 


TP_IMS_5097_09 in CFW step 6 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from IMS A addressed to UE B } 
then { IUT sends the initial INVITE to AS_B 

containing a Route_header 

indicating the SIP_URI of AS_B and 

containing a P-Charging-Function-Addresses header } 

} 




4 


TP_IMS_5108_03 in CFW step 8 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from IMS A addressed to UE B} 
then { IUT sends the INVITE to AS_B 

containing a topmost Route_header 

indicating the SIP_URI of AS_B and 
containing a Route header 
indicating the S-CSCF SIP URI of IUT } 

} 




5 


TP_IMS_51 1 8_02 in CFW step 25 and 26 (200 OK) 
ensure that { 

when { IUT receives 200_response from AS_B addressed_to UE A } 
then { IUT sends the 200_response to IMS_A 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
including a term-ioi_parameter 
indicating operator identifier of IUT } 

} 
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Step 



Direction 



Message 



Comment 
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10 



User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



l"E triggers the PIP IFC in IMS_B 
IMS B forwards the INVITE to IMS B AS 



AS optionally responds with a 100 Trying 
provisional response 



IMS_B AS returns, possibly modified, INVITE to 
IMS B 



IMS_B responds with a 100 Trying provisional 
response 



IMS B forwards the INVITE to IMS A 



11 



12 

T3~ 



14 



15 



16 



17 



18 



19 



20 



21 

22 
~23~ 

~24~ 
~25~ 



26 



27 
~28~ 
29_ 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards the INVITE to UE B 



100 Trying 



UE_B optionally responds with a 100 Trying 
provisional response 



User B is informed of incoming call of User A, 
User A's identity is displayed 



180 Ringing 



UE_B responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_A forwards 180 Ringing response to 
IMS B 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS BAS 



180 Ringing 



IMS_B AS forwards 180 Ringing response to 
IMS B 



180 Ringing 



IMS_B forwards the 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE A 



User A is informed that UE_B is ringing 



User B answers call 



200 OK 



UE_B responds INVITE with 200 OK to indicate 
that the call has been answered 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards 200 OK response to IMS_B AS 



200 OK 



IMS_B AS forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards the 200 OK response to IMS_A 



200 OK 



IMS_A forwards the 200 OK response to UE_A 



User A is informed that call has been answered 
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.5.5.3 Supplementary Services OIR and ACR with AS 



Interoperability Test Description 


Identifier: 


TD IMS 0039 


Summary: 


IMS network supports properly application services based on the example of the OIR 
and ACR supplementary services 


Configuration: 


CF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5046 01 


ES 283 003 [1], clause 5.2.6.3 %4 


TP IMS 5067 01 


ES 283 003 [1], clause 5.2.7.2 V 


TP IMS 5097 09 


ES 283 003 [1], clause 5.4.3.2 V 


Use Case ref.: 


UC_06_R 


Pre-test 
conditions: 


• HSS of IMS_A and of IMS B is configured according to table 1 

• UE_A and UE_B have IP bearers established to their respective IMS networks 
as per clause 4.2.1 

• UE_A is registered in IMS_A using userOIR identity according to table 1 

• UE B is registered in IMS B via IMS A using any userACR identity according 
to table 1 

• IMS_A is configured to contact AS_A (OIR) 

• UE_A is subscribed to ACR service IMS_B is configured to contact AS_B (OIR) 

• UE B is subscribed to ACR service 

• IMS_B is configured to contact AS_B (ACR) 

• UE B is subscribed to ACR service 



Test Sequence: 


Step 






1 


User A calls User B (i.e. userACR in IMS_B) 




2 


Verify that user A is informed that call has been rejected due to ACR 






Conformance 


Check 




Criteria: 


1 


TP_IMS_5046_01 in CFW step 8 (INVITE) 
ensure that { 

when { IMS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 
containing an additional Via_header 
containing ( the P-CSCF via port number and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF _port_number 

"where it awaits subsequent requests" from UE A and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
indicating the "list of Service Route header URIs 
from the registration" and 
not containing P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of UE A and 
containing a P-Charging-Vector_header 
containing an icid parameter } 

} 




2 


TP_IMS_5067_01 in CFW step 4 (INVITE) 
ensure that { 

when { IMS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 

containing a P-Charging-Vector_header 
containing a access-network-charging-info parameter 

} 

} 
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Interoperability Test Description 




3 


TP_IMS_5097_09 in CFW step 10 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from IMS_A addressecMo UE_B } 
then { IUT sends the initial INVITE to AS_B 

containing a Route_header 

indicating the SIPJJRI of AS_B and 

containing a P-Charging-Function-Addresses header} 

} 




4 


TP_IMS_5313_01 in CFW step 14 (433 Anonymity Disallowed) 
ensure that { 
when { IUT receives a response from IMS_B 
containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter and 
containing a P-Access-Network-lnfo header 

} 

then { IUT sends the response to AS_A 

containing a P-Charging-Vector_header 
including an access-network-charging-info_parameter and 
containing a P-Access-Network-lnfo header 

} 

} 







Step 



Direction 



Message 



Comment 
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10 



11 



12 



13 



14 



15 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



INVITE 



100 Trying 



433 

Anonymity 
Disallowed 



433 

Anonymity 
Disallowed 



433 

Anonymity 
Disallowed 



433 

Anonymity 
Disallowed 



User A calls User B 



UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE_A supports 



IMS_A responds with a 100 Trying 
provisional response 



INVITE triggers the OIR IFC in IMS_A 



IMS 
AS 



A forwards the INVITE to IMS A 



IMS_A AS optionally responds with a 
100 Trying provisional response 



IMS_A AS returns modified INVITE 
including Privacy header (value "id" or 
"header") to IMS A 



IMS_A responds with a 100 Trying 
provisional response 



IMS A forwards INVITE to IMS B 



IMS_B responds with a 100 Trying 
provisional response 



INVITE triggers the ACR IFC in IMS_B 



IMS 
AS 



B forwards the INVITE to IMS B 



AS optionally responds with a 100 Trying 
provisional response 



IMS_B AS responds with 433 Anonymity 
Disallowed to IMS B 



IMS_B forwards the 433 Anonymity 
Disallowed to IMS A 



IMS_A forwards the 433 Anonymity 
Disallowed to IMS A AS 



IMS_A AS forwards, possibly modified, 
433 Anonymity Disallowed to IMS_A 
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Step 



Direction 
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Comment 
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16 



17 



18 
19 

20 

~2T 
~22~ 



433 

Anonymity 
Disallowed 



IMS_A forwards the 433 Anonymity 
Disallowed to UE A 



User A is informed that the call has been 
rejected due to ACR 



ACK 



UE A sends ACK to IMS A 



ACK 



IMS A forwards the ACK to IMS A AS 



ACK 



IMS_A AS forwards, possibly modified, 
ACK to IMS A 



ACK 



IMS A forwards ACK to IMS B 



ACK 



IMS B forwards ACK to IMS B AS 



4.5.5.4 



Supplementary Service CFU with AS 



Interoperability Test Description 


Identifier: 


TD IMS 0040 


Summary: 


IMS network supports properly application services based on the example of the CFU 
supplementary service 


Configuration: 


CF ROAM AS 


SUT 


IMS A 


References 


Test Purpose 


Specification Reference 




TP IMS 5046 01 


ES 283 003 [1], clause 5.2.6.3 H4 




TP IMS 5067 01 


ES 283 003 [1], clause 5.2.7.2 ^7 




TP IMS 5070 01 


ES 283 003 [1], clause 5.2.7.3 H6 




TP IMS 5110 01 


ES 283 003 [1], clause 5.4.3.3 H33 




TP IMS 5097 09 


ES 283 003 [1], clause 5.4.3.2 V 




TP IMS 5108 03 


ES 283 003 [1], clause 5.4.3.3 V 




TP IMS 5118 02 


ES 283 003 [1], clause 5.4.3.3 1145 


Use Case ref.: 


UC 11 R 








Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_A and UE_B2 have IP bearers established to IMS_B as per clause 4.2.1 

• UE_A is registered in IMS_A using any user identity 

• UE_B2 is registered in IMS_B via IMS_A using any user identity 

• IMS_B is configured to contact AS_B (CFU) for userCFU 

• UE B1 is subscribed to and has activated CFU service 



Test Sequence: 


Step 






1 


User A calls User B (i.e. userCFU in IMS_B) 




2 


User A may be informed of call diversion 




3 


User B2 answers call 




4 


Verify that user A is informed that call has been answered 




6 


Verify that user B2 is informed that call is established 




7 


User A ends call 




8 


Verify that user B2 is informed that call has ended 




9 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5046_01 in CFW step 4 (INVITE) 
ensure that { 

when { IMS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 
containing an additional Via_header 
containing ( the P-CSCF via port number and 
(the P-CSCF-FQDN address or 
the P-CSCF-IP_address)) of IMS_A and 
containing an additional topmost Record-Route_header 
indicating (the P-CSCF _port_number 

'where it awaits subsequent requests' from UE A and 
(the P-CSCF-FQDN_address or 
thp P-C.^C.F-IP arltirp^)) nf IMQ A and 

lilt? 1 U Jul II aUUI&JJ// Ul IIVIiJ A1 CLl IKJ 

indicating the "list of Service Route header URIs 
from the registration" and 
not containing P-Preferred-ldentity_header and 
containing a P-Asserted-ldentity_header 

containing an address of UE A and 
containing a P-Charging-Vector_header 

containing an icidjparameter } 

j 




2 


TP_IMS_5067_01 in CFW step 4 
ensure that { 

when { IMS A receives an initial INVITE from UE Bj 
then { IMS_A sends the INVITE to IMS_B 

containing a P-Charging-Vector_header 
containinn a accp^-npfwork-charninn-infn narampfpr 

wv/ 1 C LA II II 1 1 W Ci UWvJJ 1 1 I V Irvi m ul IC4 ' 1 lu II 1 1 \J KJ <—i 1 C4I 1 Ivlvl 

; 

; 




3 


TP_IMS_5070_01 in CFW step 7 (100 Trying) 
ensure that { 

whpn I IMS A rprpivps an initial INVITF fmm I IF R I 

VV 1 1 t7x 1 ) II vlU / i i \^s\j\^>t V t70 CUI 1 II II 1 1 Gtl 1 1 V V 1 1 t 1 1 KJ ] 1 1 I I— J f 

then { IMS A sends a 100 response to IMS B 
} 

} 




4 


TP_IMS_51 10_01 in CFW step 23 (200 OK) 
ensure that { 

when { IUT receives a 200_response from AS_A addressed_to UE B } 
then { IUT sends the 200_response to IMS_B } 

j 




5 


TP_IMS_5097_09 in CFW step 12 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from IMS A addressed to UE B } 
then { IUT sends the initial INVITE to AS_B 

containing a Route_header 

indicating the SIP_URI of AS_B and 

containing a P-Charging-Function-Addresses header} 

1 




6 


TP IMS ^108 0^ in CFW stpn 6 CINVITE^ 

1 1 1 1 VI VJ ' 1 UU \J\J III w 1 V V OlCU \J I 1 1 M V 1 1 1 I 

ensure that { 

when { IUT receives an initial INVITE from IMS A addressed to UE B} 
then { IUT sends the INVITE to AS_B 

containing a topmost Route_header 

indicating the SIPJJRI of AS_B and 
containing a Route header 
indicating the S-CSCF SIP URI of IUT } 

} 
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Interoperability Test Description 




7 


TP_IMS_51 1 8_02 in CFW step 22 and 23 (200 OK) 
ensure that { 

when { IUT receives 200_response from AS_B addressed_to UE_A } 
then { IUT sends the 200_response to IMS_A 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operatorjdentifier of IMS_A and 
including a term-ioi_parameter 
indicating operator identifier of IUT } 

} 



Step 



Direction 



Message 



Comment 



u 


U 


U 


U 


I 


1 


A 


s 


E 


s 


E 


M 


M 


S 


e 


A 


e 


B2 


S 


S 


B 


r 




r 




A 


B 




A 




B2 











User A calls User B 



INVITE 



UE_A sends INVITE with the first SDP 
offer indicating all desired media and 
codecs that UE_A supports 



100 Trying 



IMS_A responds with a 100 Trying 
provisional response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying 
provisional response 



INVITE triggers the CFU IFC in IMS_B 



INVITE 



IMS B forwards the INVITE to AS B 



100 Trying 



AS_B optionally responds with the 100 
Trying to IMS_B 



181 Call is 

being 

forwarded 



AS_B applies the CDIV CFU procedure 



AS_B indicates optionally to IMS_B that 
call has been forwarded 



10 



11 

T2~ 



13 



14 

T5~ 

T6~ 
17 



18 



20 



21 



22 



181 Call is 

being 

forwarded 



IMS_B indicates to IMS_A that call has 
been forwarded 



181 Call is 

being 

forwarded 



IMS_A indicates that call to UE_B has 
been forwarded 



User A may be informed of call diversion 



INVITE 



AS_B returns modified INVITE including 
new request URI and history header to 
IMS B 



100 Trying 



IMS_B responds with a 100 Trying 
provisional response 



INVITE 



IMS B forwards the INVITE to IMS A 



100 Trying 



IMS_A responds with a 100 Trying 
provisional response 



INVITE 



IMS A forwards the INVITE to UE B2 



100 Trying 



UE_B2 optionally responds with a 100 
Trying provisional response 



User B2 is informed of incoming call of 
User A 



JserB2 answers call 



200 OK 



UE_B2 responds to INVITE with 200 OK 
to indicate that the call has been 
answered 



200 OK 



IMS_A forwards 200 OK response to 
IMS B 



200 OK 



IMS_B forwards 200 OK response to 
AS B 
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Step 


Direction 


Message 


Comment 
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A 






B2 
























23 


















200 OK 


AS_B returns, possibly modified, 200 OK 
to IMS B 


t 


24 


200 OK 


IMS B forwards 200 OK response to 
IMS A 


t 


25 


200 OK 


IMS A forwards 200 OK response to 
UE A 


i 






26 




















User A is informed that call has been 
answered 


i 



.5.5.5 Supplementary Services OIP and OIR with AS 



Interoperability Test Description 


Identifier: 


TD IMS 0041 


Summary: 


IMS network supports properly application services based on the example of the OIP 
and OIR supplementary services 


Configuration: 


CF ROAM AS 


SUT 


IMS B 


References 


Test Purpose 


Specification Reference 


TP IMS 5097 02 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5097 03 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5097 09 


ES 283 003 [1], clause 5.4.3.2 V 


TP IMS 5108 03 


ES 283 003 [1], clause 5.4.3.3 V 


TP IMS 5118 02 


ES 283 003 [1], clause 5.4.3.3 f*5 


Use Case ref.: 


UC 09 R 



Pre-test 


• HSS of IMS_A and of IMS B is configured according to table 1 


conditions: 


• UE_A and UE_B have IP bearers established to their respective IMS networks 




as per clause 4.2.1 




• UE_A is registered in IMS_A using userOIP_priv identity according to table 1 




• UE B is registered in IMS B via IMS A using userOIR priv identity according 




to table 1 




• IMS_A is configured to contact AS_B (OIP) 




• UE A is subscribed to OIP service 




• IMS_B is configured to contact AS_A (OIR) 




• UE B is subscribed to OIR service 



Test Sequence: 


Step 






1 


User B calls User A (i.e. userOIR in IMS_A) 




2 


Verify that user A is informed of incoming call of User B and User B's 
identity is not displayed 




3 


Verify that user B is informed that UE_A is ringing 




4 


User A answers call 




5 


Verify that user B is informed that call has been answered 




6 


Verify that user A is informed that the call is established 




7 


User A ends call 




8 


Verify that user B is informed that call has ended 




9 


Verify that user A is informed that call has ended 
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Interoperability Test Description 



Conformance 


Check 




Criteria: 


1 


TP_IMS_5097_02 in CFW step 4 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from UEA addressed_to UEB 
not containing a P-Preferred-ldentity_header or 

not indicating a Tel URI of UE A } 
then { IUT sends the initial INVITE to IMS_B 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE A 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel URI of UE A} 

} 




2 


TP_IMS_5097_03 in CFW step 4 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from UE A addressed_to UE B 
not containing a P-Preferred-ldentity_header or 

indicating a Tel_URI of UE_A} 
then { IUT sends the initial INVITE to IMS_B 

containing a P-Asserted-ldentity_header 

indicating the default_registered_public_identity of UE A 
and 

containing a P-Asserted-ldentity_header 
indicating a Tel derived SIP URI of UE A} 

j 




3 


TP_IMS_5097_09 in CFW step 6 (INVITE) 
ensure that { 

when { IUT receives an initial INVITE from IMS A addressed to UE B } 
then { IUT sends the initial INVITE to AS_B 

containing a Route_header 

indicating the SIP_URI of AS_B and 

containing a P-Charging-Function-Addresses header } 

} 




4 


TP IMS ^108 03 in CFW stpn 8 CINVITE^ 

1 1 1 1 VI Vj U 1 UU U J III \J 1 V V OlCU (J 1 1 1 N V 1 1 1 / 

ensure that { 

when { IUT receives an initial INVITE from IMS A addressed to UE B} 
then { IUT sends the INVITE to AS_B 

containing a topmost Route_header 

indicating the SIP_URI of AS_B and 
containing a Route header 
indicating the S-CSCF SIP URI of IUT } 

} 




5 


TP_IMS_51 1 8_02 in CFW step 35 (200 OK) 
pn^/zrp that ( 

when { IUT receives 200_response from AS_B addressed_to UE A } 
then { IUT sends the 200_response to IMS_A 
containing a P-Charging-Vector_header 
including a orig-ioi_parameter 

indicating operator Jdentifier of IMS_A and 
including a term-ioi_parameter 
indicating operator identifier of IUT } 

} 
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Step 



Direction 



Message 



Comment 
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A 
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S 


B 
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A 




B 




A 




B 













10 

11 



12 

T3~ 



14 



15 



16 
17 



18 



19 



20 
21 



22 



23 



24 



25 



26 



27 
~28~ 
29 

~30~ 
31 

~32~ 
33 



User B calls User A 



INVITE 



UE_B sends INVITE with the first SDP offer 
indicating all desired media and codecs that 
UE_B supports 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards INVITE to IMS B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



INVITE triggers the OIR IFC in IMS_B 



IMS B forwards the INVITE to IMS B AS 



100 Trying 



INVITE 



IMS_B AS optionally responds with a 100 Trying 
provisional response 



IMS_B AS returns modified INVITE including 
Privacy header (value "id" or "header") to IMS_B 



100 Trying 



IMS_B responds with a 100 Trying provisional 
response 



INVITE 



IMS B forwards the INVITE to IMS A 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE triggers the PIP IFC in IMS_A 



INVITE 



IMS A forwards the INVITE to IMS A AS 



100 Trying 



IMS A AS optionally responds with a 1 00 Trying 
provisional response 



INVITE 



IMS_A AS returns modified INVITE including 
modified From and P-Asserted headers to 
IMS A 



100 Trying 



IMS_A responds with a 100 Trying provisional 
response 



INVITE 



IMS A forwards the INVITE to UE A 



100 Trying 



UE_A optionally responds with a 100 Trying 
provisional response 



180 Ringing 



UE_A responds to initial INVITE with 180 
Ringing to indicate that it has started alerting 



180 Ringing 



IMS_A forwards the 180 Ringing to IMS_A AS 



180 Ringing 



IMS_A AS forwards, possibly modified, 180 
Ringing to IMS_A 



180 Ringing 



IMS_A forwards 180 Ringing response to 
IMS B 



180 Ringing 



IMS_B forwards 180 Ringing response to 
IMS BAS 



180 Ringing 



IMS_B AS forwards, possibly modified, 180 
Ringing response to IMS_B 



180 Ringing 



IMS_B forwards the 180 Ringing response to 
IMS A 



180 Ringing 



IMS_A forwards the 1 80 Ringing response to 
UE B 



User B is informed that UE_A is ringing 



200 OK 



User A answers call 



UE_A responds INVITE with 200 OK to indicate 
that the call has been answered 



_ 



200 OK 



IMS A forwards the 200 OK to IMS A AS 



200 OK 



IMS_A AS forwards, possibly modified, 200 OK 
to IMS A 



200 OK 



IMS_A forwards 200 OK response to IMS_B 



200 OK 



IMS_B forwards 200 OK response to IMS_B AS 
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200 OK 


IMS_B AS forwards, possibly modified, 200 OK 
response to IMS_B 


35 


200 OK 


IMS_B forwards the 200 OK response to IMS_A 


36 




200 OK 


IMS_A forwards the 200 OK response to UE_B 
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